Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 51 additions & 12 deletions en/ai-sre/automations.mdx

Large diffs are not rendered by default.

7 changes: 6 additions & 1 deletion en/ai-sre/im.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ sidebarTitle: IM platform

Incident response usually happens right inside your IM group — alerts come in, the team discusses in the channel, and someone spins up a war room. AI SRE puts the agent directly into that collaboration chain: **you never have to switch to the console. You can summon it from IM to investigate**, and your teammates can follow every step of its analysis in real time.

AI SRE's IM integration has two trigger modes:
AI SRE's IM integration has three trigger modes:

<CardGroup cols={2}>
<Card title="@Mention Summon" icon="at">
Expand All @@ -20,8 +20,13 @@ AI SRE's IM integration has two trigger modes:
<Card title="War Room Auto-Diagnosis" icon="people-group">
When someone opens an IM war room for an incident, AI SRE runs a preliminary diagnosis and posts the findings to the war room if the account has an enabled **War room created** automation rule that the incident's channel and severity match. No one needs to summon it.
</Card>
<Card title="Automation Replies in the Group" icon="clock">
Ask AI SRE in the group to create an ordinary automation rule and it pins **this group** as where the rule runs: when that rule fires on schedule, through the API, or on an On-call incident, it runs the turn in the original group in a **fresh session** and posts the findings back there. Every run is a brand-new session and carries none of the group's conversation history; if the IM integration uses thread replies, the run also starts a new thread, whose root is the first real output of that run (progress or findings) and whose later progress and findings are replies inside it — nothing like a canned "started" message is posted before there is content. The binding and scope are fixed at creation and cannot be moved to another group: AI SRE re-checks them before the run and **skips the entire run** if the group's team scope or session has changed, and if the same rule already has a run active in that group, this occurrence does not queue either — it is skipped too.
</Card>
</CardGroup>

The first two modes are initiated by a person; the third runs from an automation rule you set up. For how to create the rule and how its run location and scope are pinned, see [Automations · Configuration fields](/en/ai-sre/automations#configuration-fields).

## Supported IM platforms

AI SRE's IM interaction covers four major platforms. Each platform supports inbound @mentions (webhook), historical message reads, and outbound replies:
Expand Down
1 change: 1 addition & 0 deletions en/ai-sre/sessions.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -86,6 +86,7 @@ Type a message in the input and press Enter. The input supports Markdown; type `

- **Supported types**: images, PDF, text / Markdown / CSV / HTML, Office documents, archives (`.zip` / `.rar`), and any UTF-8 text file (such as `.go`, `.py`, `.yaml`). Empty files are rejected.
- **Size and count**: up to **50 MB** per file; up to **9 attachments** per message, **50 MB** in total.
- **Images**: so that every vision model can read them, an image whose longest side is over **8192 px**, whose shortest side is under **11 px**, or whose long-to-short ratio is over **200:1** is scaled down, padded with white, and **re-encoded** — the stored format can change (a GIF is stored as PNG and only its first frame survives) and the file name's extension is adjusted to match. Such an image is rejected outright if it holds more than **40 megapixels**, with a prompt to send a smaller one. An image that is corrupt, or an unrecognized variant, fails to upload. Images inside a folder are stored as sent and get none of this treatment.
- **Folders**: choose **Upload folder** from the plus menu or drag a folder onto the input. A folder can hold up to **50 files** (`node_modules` and dot-files are not counted). A larger folder is rejected as a whole, and individual files that do not qualify are skipped with the reason listed. A folder counts as 1 attachment and keeps its directory structure.
- **How the agent reads them**: attachments are provided as text. For text over 64 KB only the beginning is provided directly, and the agent reads the full file from the sandbox when needed. Archives and folders are not expanded up front; the agent unpacks and reads them in the sandbox as needed.
</Accordion>
Expand Down
28 changes: 28 additions & 0 deletions en/changelog/changelog.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,34 @@ description: "This page documents important updates and feature releases for Fla
keywords: ["Changelog", "Product Release", "Feature Updates", "Flashduty", "Version History"]
---

<Update label="2026-10-16" description="🤖 AI SRE automations can run in the IM chat that created them, RUM issues gain a resolve mode, DingTalk and Lark integrations link members automatically on save">

### AI SRE automations: an execution location that can bind a rule to the IM chat that created it

An automation rule now carries an **execution location**, fixed at creation: **Web** (the default) or **IM**. When you have the Agent create a rule in an IM group chat or DM, the rule binds to **that conversation** (an API call that passes `run_in: current-chat` does the same, but that value is only accepted from the live IM conversation). Both create entries in the console always produce a rule with the **Web** execution location, and an IM rule offers no **Clone** action in the console either, so running a rule in a different location means creating a new one. The execution location cannot be changed after creation: the edit form shows the scope and the execution location as read-only, with the hint "The scope and IM destination were fixed at creation and cannot be changed in the console." beside an IM rule.

A rule with the IM execution location never opens a session in the console. Every run **opens a new session** in the original group chat, plus a new topic when the integration has threads on; a retry of the same run keeps that session and thread, the original group chat never changes, and the conclusion is posted back into that chat. If the chat's scope or session has changed by the time the rule runs (say `/scope` or `/new` was used), that run is **skipped** (status "Skipped" in the run history, reason `chat_scope_mismatch`); the rule stays enabled and never moves to another chat.

The rule list gains a column for the execution location, with the values `IM` / `Web`; when a rule has both a war room trigger and other triggers, that column shows two badges — "War room → IM" and "Other triggers → Web". See [AI SRE automations](/en/ai-sre/automations).

### RUM issues: a resolve mode — Resolved / Resolved in next version

**Resolved** and **Resolved in next version** in an issue's status dropdown are one resolved status split by how a recurrence reopens the issue:

- **Resolved** (the dropdown says "Reopens if it occurs again"): the error occurring again reopens the issue as For Review and marks it **Issue Regression**, even in the same version;
- **Resolved in next version** ("Reopens only if it occurs in a newer version"): only a recurrence in a version the issue has not seen before reopens it, while repeats inside the same version leave it resolved.

You can switch between the two in the status dropdown at any time. A new issue defaults to **Resolved in next version**, and existing issues carry that same default; an error that reports no version label reopens the issue under either mode. See [Issue status](/en/rum/error-tracking/issue-status).

### DingTalk and Lark integrations link members automatically on save

Saving or editing a DingTalk or Lark integration starts one link attempt right away, and once an hour the system sweeps every enabled DingTalk and Lark integration: it resolves each member's phone number (and, for Lark, email) to an IM account ID and writes the binding. Members do nothing, and they no longer have to sign in to the IM app first. Click **Link users** on the integration detail page only when you want to retry immediately.

An IM account ID another member already holds is never overwritten; a member the platform answers "no such user" for is not looked up again for 7 days; and when a DingTalk app lacks the `qyapi_get_member_by_mobile` permission or its server IP is not whitelisted, or a Lark app lacks the contacts permission, automatic linking for that integration pauses for 24 hours — fix the permission or the whitelist and save the integration again to resume. Automatic linking covers DingTalk and Lark only; WeCom still uses the manual **Link users** button, and Slack integrations offer no member linking at all. See [DingTalk](/en/on-call/integration/instant-messaging/dingtalk) and [Lark](/en/on-call/integration/instant-messaging/lark).

</Update>


<Update label="2026-10-14" description="🧭 Investigation entries open the exact dashboard or query from an alert, alert-grouping rework, label-panel redesign, weekly and monthly scheduled notifications, dashboard global search">

### Investigation entries: from an alert straight to a dashboard or the Query Workbench
Expand Down
Loading