Now

AI SRE has finished its gradual rollout and is now in open public beta for every Flashduty account.

Starting today:

• No application — the beta request form and allowlist are gone; the AI SRE entry is visible to all accounts by default;
• Sign in and go — open Flashduty console → AI SRE, pick a recent real alert, and let it investigate first;
• Free during the beta — no separate billing; commercial pricing will be announced ahead of general availability, and charges will not start without confirmation.

If your team lives in Slack, Feishu, DingTalk, or WeCom: when a war room opens for an incident, AI SRE automatically runs a first round of diagnosis and posts its findings back to the group — @ it in the chat to follow up.

For a first run, walk through the quickstart: bind an incident, watch it return a conclusion with an evidence chain — about five minutes. For the full picture, see the AI SRE overview.

A report the Agent builds mid-session, an /insight summary for example, is useful in the moment and hard to find again once the chat window closes. You either scroll back through history or ask the Agent to run it a second time.

The Artifacts gallery is now live. It collects the pages and reports the Agent produces with present_files and then publishes with publish_artifact, with search, scope filtering, renaming, sharing, downloading, and deletion.

Published from a session, not uploaded by hand

The gallery has no create-file entry of its own. Every artifact comes from something the Agent produced in a session. Two paths lead there: click New Artifact in the gallery and it opens a session with a prefilled prompt, the Agent asks about your audience, content, interaction, and visual style before building and publishing; or, more directly, any file the Agent surfaces with present_files in a chat carries its own Publish to gallery button.

Refreshes when the source changes, permissions follow scope

An artifact starts in the scope of the session that made it: output from a personal session belongs to its creator, output from a team-bound session belongs to that team and can be shared with other account members. You can move it between personal and any team you can access afterward. If the Agent later edits and re-presents the same source file, the published artifact updates in place, no manual republish needed. Who can rename, change scope, or delete depends on your relationship to the artifact: the creator, an account owner or admin, or, for team-scoped artifacts, any other member of that team. Without those rights you only get read actions like copy link and download.

IM and API still answer in text by default

The web console renders a published artifact as a card in chat. On IM, API, and automation channels, the Agent still answers in plain text by default, and only publishes when you explicitly ask to keep or share the output, or when the content itself needs rich formatting like charts or long tables, adding the link to its reply. That restraint is deliberate: most of the time a clear text answer beats an extra link to click.

Getting started

Go to Flashduty console → AI SRE → Artifacts.

See the product documentation for details.

AI SRE is rolling out to On-call Professional accounts and above, as part of the ongoing public beta.

Debugging a pod that keeps restarting usually takes more than metrics and logs. You need the pod's current state, its events, and what changed recently, and that information lives in the cluster, out of the Agent's reach.

The Kubernetes App is now live, bringing a cluster into AI SRE's investigation flow. It uses the same mechanism as the GitHub App and GitLab App for repository access, the Customize App primitive, applied here to a cluster instead of a repository.

Permissions scoped to the namespace

Creating a Kubernetes App starts with a cluster name and a scope: Shared makes it available to any session in the account, or Team limits it to that team's sessions and the personal sessions of that team's members. For namespaces, choose All namespaces to apply one permission level across current and future ones, or Specific namespaces to pick read-only or read + limited write for each one individually. Leave namespaces unspecified and the Agent can only read basic cluster metadata, nothing about individual workloads. Installing the App does not hand the Agent the whole cluster.

You run the install command yourself, the console doesn't do it for you

After saving the configuration, the console generates an install command for you to run against the target cluster yourself. The command expires; reopen the install config or check the Manifest for a fresh one, no token rotation required. Change the namespace or permission scope later and you need to rerun the install command for the in-cluster RBAC to catch up.

Revoking and uninstalling are two separate steps

Revoking in the console immediately invalidates the connection and its token, but it does not automatically remove the Agent or RBAC resources already installed in the cluster. The console provides an uninstall command for that; run it against the cluster yourself. It only removes what this particular Kubernetes App installed, leaving the shared flashduty namespace untouched.

Getting started

Go to Flashduty console → AI SRE → Plugins → Apps → Kubernetes App.

See the product documentation for details.

AI SRE is rolling out to On-call Professional accounts and above, as part of the ongoing public beta.

The difference between an Agent that only advises and one that goes and checks is whether it has somewhere to work.

Every AI SRE investigation runs in a real execution environment: running commands, calling APIs, processing data, producing reports. That environment comes in two forms, and you pick based on where your systems live.

Cloud Sandbox: works out of the box

The default. Flashduty hosts it, creates it on demand when a session starts, and runs it in isolation. It ships with the command-line tools an investigation usually needs, so the Agent can read and write files, run scripts, and call public APIs directly. You can also give the cloud environment an egress allowlist, environment variables, and an init script, so every new Sandbox comes up matching your team's conventions.

BYOC Runner: put execution inside your network

When the systems under investigation sit on an internal network, a public environment cannot reach them. Deploy a Runner on your own machine instead, and the Agent executes from inside your network.

The Runner dials out to establish the connection, so you never open an inbound port for it and never expose internal addresses to the public internet. It bundles the tooling an investigation needs, including rg, jq, gh, and the Node and Python runtimes, so there is nothing to install one by one afterward. It updates itself on every platform as server-side capabilities move forward, with no manual upgrade step.

You still draw the execution boundary

In either environment, what the Agent may write, which credentials it can use, and what network it can reach all follow your configuration. Production changes, restarts, rollbacks, and outbound notifications always wait for a human to confirm.

Getting started

Go to Flashduty console → AI SRE → Environments, where the tabs at the top switch between Self-hosted and Cloud.

See the product documentation for details.

This is available to On-call Professional accounts and above, alongside the AI SRE public beta.

Investigations tend to stall at the same point: the logs name a function, and nobody can say offhand who changed those lines recently or why.

AI SRE now connects to your code repositories. Both the GitHub App and the GitLab App are available, and the GitLab App has finished its allowlist rollout and is open to all accounts.

Extend the investigation into the source

Once authorized, the Agent can clone a repository, search the code, and read commit history and PR discussions. When it hits an unfamiliar function in a stack trace, it checks the implementation in the repository instead of answering from the model's impression. It also reads whatever conventions the repository ships with, such as CLAUDE.md or AGENTS.md, and follows your team's rules.

From the error back to the commit

Combining Flashduty's change records with repository history, the Agent can line up an exception with the commit that introduced it. One real case we recorded: a user triggered the same frontend exception three times, RUM preserved the session and the SourceMap stack, and AI SRE traced it to a form initialization bug, made a one-line fix, and opened a PR. Eight minutes from the last error. The full account is here.

It opens a PR only when asked

The Agent does not touch your code on its own initiative. Only when you explicitly ask for a fix in the session will it create a branch, commit the change, and open a PR for your team's normal review process. Whether a finding is worth a code change stays a human call.

Tokens are injected per turn

The repository access token is injected into the execution environment on each tool-calling turn, through the same path for a cloud Sandbox and for a BYOC Runner you host yourself. The authorization record stays in Flashduty, tokens can be rotated, and you can revoke access from the console at any time.

Getting started

Go to Flashduty console → AI SRE → Plugins → Apps and authorize GitHub or GitLab.

See the product documentation for details.

This is available to On-call Professional accounts and above, alongside the AI SRE public beta.

In the first ten minutes after an alert fires, most of an on-call engineer's time goes into assembling context rather than making a judgment.

The alert lives in the monitoring platform, the incident timeline in Flashduty, the deploy in the release system, metrics and logs behind their own entry points, and the troubleshooting steps in a team document. Paste all of that into a general-purpose chat box and it can explain what usually exhausts a connection pool, but it does not know which change caused this one or which instances are failing.

AI SRE is now in public beta, rolling out to On-call Professional accounts and above. It spent the past few months handling real alerts in private beta, and the door is now open.

The session does not start blank

Type @ in a new console conversation to reference an incident, and the Agent enters with that incident's alerts, services, teams, and on-call assignments already loaded. It plans its investigation from there instead of asking you what happened. The same applies when you summon it from your IM, where the war room discussion is also in view.

It calls the tools you already connected

MCP connectors reach your monitoring, logging, and cloud platforms. The built-in catalog currently offers 35 connectors. Your team's own troubleshooting procedures can be written up as Skills, and background about your systems goes into the knowledge base, so the Agent reuses both without being briefed again each time.

Execution can run inside your network

By default the Agent works in a Flashduty-hosted cloud Sandbox. When an investigation needs to reach internal systems, deploy a BYOC Runner in your own network. It dials out to establish the connection, so you never open an inbound port for it.

Production actions stop with you

The Agent finishes the investigation and proposes a root cause and next steps, but changes, restarts, rollbacks, and outbound notifications still wait for your confirmation. This boundary does not loosen during the beta.

Getting started

Go to Flashduty console → AI SRE → New chat.

See the product documentation for details.

AI SRE is now in open public beta — no application needed; sign in to the console and start using it. There is no separate charge during the beta, and the feature set and interface may still change.

Filtering for "Chrome errors that took over 2 seconds" in the RUM Explorer meant knowing the right field names and how to combine operators first. If you did not use DQL often, that step alone could stop you before you got to the data.

The Explorer now accepts a plain-language description of what you want to find. Whether you are filtering sessions or events such as views, resources, and errors, AI turns the description into the matching DQL query.

Describe it in one line, AI writes the query

Click the AI Natural-Language Query icon on the left of the query field, or press ⌘+Enter (Ctrl+Enter on Windows/Linux) from normal query mode. The field switches to natural-language input. Press Enter and AI returns a preview: the generated DQL shows as a code snippet you can see and copy before applying anything. If the description fits a different event type better, the preview calls that out as a separate change. Clicking apply writes the DQL into the query field, where it behaves exactly like anything you typed by hand and can be edited further. The success toast after applying includes an Undo.

Time phrases resolve in your timezone, capped at 14 days

Phrases like "last hour" or "yesterday" are converted using your account's timezone and update the time picker directly, rather than turning into a query field. If the requested span exceeds 14 days, such as "the past month," it is automatically clamped to the most recent 14 days, and the preview flags the truncation. This ceiling matches the Explorer's own maximum query range. It is not a limit specific to natural-language queries.

Getting started

Open the RUM Explorer and click the AI icon on the left of the query field. See the product documentation for details.

You want the responder to leave a note when they acknowledge an incident, or confirm the blast radius before closing it. Until now there was nowhere in Flashduty to collect that, so teams fell back on chat threads or a separate ticketing system.

Custom incident forms now let you configure a separate form for each of three actions: create incident, acknowledge incident, and resolve incident. A form can include custom fields, a free-text note, and image uploads, and each element can be set to required or optional, and shown only when a condition is met, for example requiring the impact scope field only when severity is high.

Written atomically with the state change

Submitting an acknowledge or resolve form and updating the incident state happen as a single atomic write. You will not see a form get submitted while the state change fails to apply, or the state change go through while the submitted content is lost.

One interface across five IM platforms

Tapping acknowledge or resolve in DingTalk, Feishu, Slack, Microsoft Teams, or WeCom opens the same Console H5 form drawer. There is no separate form implementation per platform, so the experience is identical regardless of which IM the responder is using.

Configuration and list pages rebuilt

The field configuration and form management pages were redesigned. Drag to reorder fields, and click any row to edit its display condition, required rule, and help text.

Mobile fix included

In the mobile app, acknowledging or resolving an incident with no form configured no longer redirects to an empty form page first. It completes the action directly.

Getting started

Go to the incident configuration section of the Flashduty console and open Custom Forms.

See the product documentation for details.

Before a company adopts a SaaS tool, its security lead's review checklist almost always asks the same questions: can password login be turned off, can an API key's permissions be scoped down to the minimum, is there protection against repeated failed logins, and what happens to an account after an employee leaves.

These questions used to get addressed piecemeal across separate releases. This update brings several related changes together. As a Flashduty account grows, sign-in methods, integration keys, and membership changes all become things a security review will ask about. The four changes below cover login, key authorization, self-hosted environments, and member management. Coverage differs between SaaS and self-hosted deployments, noted in each section.

Enforce SSO, turn off password login

After configuring SAML2.0, OIDC, or CAS under Platform Management → Single Sign-On, you can turn on "Members can only sign in via SSO." Once enabled, every member of the account must authenticate through the identity provider, and password or verification-code login is rejected. This toggle is on by default the first time you configure SSO, and can be turned off if needed. Self-hosted deployments also support LDAP under the same toggle.

App Keys move from all-access to scoped permissions

Previously, an App Key could only be created with access to every API. Now, when creating or editing a key, you can choose custom permissions and select the specific API permission points that key actually needs; calls outside that scope are rejected. Even a key with full permissions stays bounded by its creator's current role permissions. Existing keys can also have their scope edited after the fact, which pairs well with rotating keys regularly to keep each key's exposure limited to what the business actually needs.

Self-hosted: brute-force protection on login, configurable session length

In self-hosted deployments, exceeding the failed-login limit now triggers a CAPTCHA, reducing the risk of password brute-forcing. Session expiration is also now configurable, so a team can set login session length according to its own security policy instead of a fixed default. Both of these are currently available only in self-hosted deployments, not on SaaS.

Stricter identity mapping, more thorough member deletion

For SSO, the user ID mapping field is now optional, and the provider_key identity dimension has been removed, reducing login issues caused by identity provider field changes. When multiple new members sign in via SSO for the first time at once (JIT account creation), account creation is now serialized to avoid duplicate accounts under concurrency. Deleting a member from the Team & Members page now comes with more complete cleanup logic, reducing leftover associated data after deletion.

Getting started

The SSO enforcement toggle is under Platform Management → Single Sign-On, see the SSO documentation for setup steps. Scoped App Keys are created under Account Settings → APP Key, see the Open API documentation for authentication and permission details. Member deletion is under Platform Management → Member Management, see the team and member documentation for details.

For brute-force protection and session length configuration in self-hosted deployments, contact our support team for deployment guidance.

A crash stack is usually a list of memory addresses or obfuscated short names. It doesn't tell you which function or which line of code failed until a symbol file maps it back to the real source. This update fills in symbolication for WeChat Mini Programs, HarmonyOS, and Android NDK native code, joining the Web and iOS support already in place, so RUM now covers most of what runs in production.

Here's how it works: a SourceMap, ProGuard mapping file, or debug symbol file generated at build time records how minified or obfuscated positions map back to the original source. Once uploaded, RUM matches incoming crash events by service name and version, then resolves the addresses or short names in the stack into real function names, file names, and line numbers.

WeChat Mini Program RUM

Production error stacks used to show only the transformed file path and line/column numbers. You can now run miniprogram-ci get-dev-source-map to generate a sourcemap and upload it through the Flashduty CLI for automatic resolution. Issue grouping and a dedicated Mini Program dashboard are also in place.

HarmonyOS RUM

A HarmonyOS crash stack can mix ArkTS/JS frames with native .so frames. Once the @flashcatcloud/hvigor-plugin is installed, the build automatically uploads the ArkTS sourcemap and the unstripped native symbol files, so both frame types resolve in the console. The dashboard and symbol management page now support HarmonyOS, and a Trace integration guide has been added.

Android NDK Native Crash Symbolication

We fixed a grouping bug that was splitting a single NDK crash site into several unrelated issues. Upload the unstripped .so file with its GNU build-id, and the C/C++ crash address resolves to a function name and line number. Native startup metrics now separate cold start from warm start instead of reporting them together.

Alert Decoupling and Private Deployment

RUM alerts used to require the On-call module to reach anyone. They can now be delivered as a Webhook POST straight to your own endpoint, so a self-hosted, RUM-only deployment without On-call can still receive alerts. The SDK also supports a custom data ingest endpoint and CDN for private deployments.

Getting started

Go to Flashduty console → RUM → App Management → Source Management to upload symbol files for your platform. Alert delivery is configured under "App Management → Alert Settings."

See Source Mapping and Error Tracking and Issue Alerts for details.

Switching away from Atlassian Statuspage is rarely about standing up a new page. The hard part is carrying over history and subscriber relationships intact, otherwise every subscriber's email link and RSS feed breaks.

Flashduty Status Page shipped late last year. This update covers two things: a real migration path from Atlassian Statuspage, and a custom domain setup rebuilt to hold production traffic.

One-click Atlassian Statuspage migration

Migration runs in two CLI steps. flashduty statuspage migrate structure imports components, groups, history events, and notification templates without notifying subscribers, so you can check the result before going further. Once it looks right, flashduty statuspage migrate email-subscribers imports the mailing list. History event feeds keep Atlassian's history.rss and history.atom URL format, so subscribers never have to update their feed URLs. Both commands are paginated and idempotent, so re-running them does not duplicate data.

Custom domains 2.0

Custom domains used to resolve through a single CNAME target. They now resolve through separate mainland China and international routes. Certificates are issued and renewed automatically by Caddy, with an idempotency fix that prevents duplicate certificate requests under concurrent traffic. Existing customers on the old single-CNAME setup keep working without any DNS changes.

RSS/Atom feeds and one-click unsubscribe

Public status pages now support RSS/Atom subscriptions, no email confirmation required. The history route also accepts an Atlassian-compatible alias, so subscribers migrating over keep their old feed URLs. On the email side, notification emails now carry the RFC 8058 List-Unsubscribe header, so Gmail, Apple Mail, Outlook, and Yahoo show a native unsubscribe button at the top of the message that takes effect immediately.

Fix

Components hidden on an internal status page no longer leak into the public change history.

Getting started

Go to Flashduty console → Status Pages → Settings to configure a custom domain. Migration steps and CLI commands are in Get started with Flashduty Status Page; feature comparison is in Status Page Comparison.

Restoring service doesn't mean the incident is truly over. The real closure begins with a post-mortem.

In practice, many teams quickly return to business as usual once an incident is resolved: root cause analysis is scattered across chat messages, follow-up actions remain verbal agreements, and similar issues quietly resurface down the road. The previous Resolution feature only supported basic field-level recording, falling short of a complete, structured post-incident analysis workflow.

To address this, Flashduty officially introduces Post-Mortem, fully replacing the former Resolution. From incident review and root cause analysis to corrective action tracking, Post-Mortem helps teams build a more complete retrospective process, turning every incident into reusable organizational knowledge, rather than a forgotten cost.

If you previously relied on custom data fields in Resolution, you can continue to achieve the same through Custom Fields.

AI-Assisted Generation: Quickly Produce a Post-Mortem Draft

Post-Mortem supports AI-generated report drafts. The system synthesizes incident details, response timelines, and discussion threads from Lark or Slack war rooms to automatically outline the sequence of events and extract key insights. This significantly reduces the effort needed to get started, allowing teams to focus on analysis and improvement.

Real-Time Collaborative Editing: Reach Consensus More Efficiently

An incident is never one person's responsibility, and neither should the post-mortem be. Multiple team members can co-edit the same report simultaneously, with changes synced in real time and auto-saved. No more passing documents back and forth or manually merging versions -- the entire team can align on facts, fill in details, and build consensus on a single page.

Template System: Never Miss What Matters

What happened? Why did it happen? How do we prevent it from happening again?

Post-Mortem provides built-in templates covering six core sections: Summary, Root Cause, Impact, Timeline, Corrective Actions, and Lessons Learned. You can also create custom templates to codify your team's best practices into a standard workflow, ensuring every post-mortem is thorough, consistent, and high-quality.

Incidents are inevitable, but the same issue happening twice doesn't have to be. With Flashduty Post-Mortem, teams can document root causes more clearly, track improvements more consistently, and accumulate lessons more systematically. This is more than a report. It's where organizational resilience begins to grow.

Get Started

Head to Flashduty Console -> On-call -> Post Incident to start using it.

For more details, refer to the Flashduty documentation.

This feature is available on the Flashduty Professional plan.