Now

When an incident hits, your users' first instinct is to check your website or help center for answers. If your status page lives at an address they don't know, even the timeliest updates won't reach them.

Flashduty Status Pages now ship with embeddable widgets: a snippet you can paste into any website's HTML to show your live service status on your own site, help center, or internal system — meeting your users where they already are.

Two forms, two jobs

• Status badge: an always-on indicator of your current overall status, available in three sizes, linking straight to your full status page — perfect for a footer or help-center home.
• Incident banner: hidden by default and only appears at the top or bottom of the page during an ongoing incident or maintenance. Visitors can dismiss it, and scheduled maintenances show up automatically 24 hours before they start, so your users can plan ahead.

Ready to use, styled your way

Under Status page detail → Settings → Widget, you can configure the theme (auto / light / dark), language (Chinese / English), badge size, and banner position, preview the result live, and copy the embed code in one click. The widget runs as a Web Component with styles fully isolated from the host page, refreshes status every 30 seconds, and pauses automatically when the tab is hidden.

A public JSON API, for everything else

Beyond the ready-made components, every public status page exposes a keyless status summary endpoint, GET {status-page-url}/api/widget/v1/summary.json, with CORS and ETag support. Build your own rendering, feed an internal dashboard, or integrate status into any system you run.

Widgets are enabled by default for all public status pages — no configuration required.

Try it now

Go to Flashduty console → On-call → Status Pages, open any public status page's Settings → Widget, and generate your embed code.

Learn more in the product documentation.

Since the artifact gallery shipped, sharing a report the agent produced came with a precondition: the recipient had to sign in to the same Flashduty account. But the people who actually need to read that report are often outside the account — a customer, an external partner, a colleague who hasn't been onboarded yet, or a link you need to paste into a ticket.

Public links are now available. On an artifact's detail page, click Share and switch visibility from Account only to Public link. Once generated, anyone with the link can open it directly — no sign-in, no Flashduty account required.

What they see is a snapshot, not live content

A public link shows the content as it was the moment you generated the link. If the agent updates the artifact later, the public link does not silently follow — that's deliberate: what you shared doesn't change behind your back. When a newer version is detected, the share panel offers Update snapshot; one click syncs the public content to the latest version, and the link itself stays the same, so links you've already sent keep working.

When you no longer want it public, click Revoke public link and it stops working immediately.

You're warned before it goes out

Public means forwarding you can't control, so there's an explicit notice before you generate: anyone with the link can view the artifact, and the link may be forwarded further — don't share secrets, personal information, or unauthorized third-party content. The share panel also lists who holds manage permission on the artifact, so you know who can change its sharing state.

Artifacts larger than 16 MiB can't generate a public link; those can still be shared in account-only mode.

More file types can be published

Artifacts are no longer limited to HTML and Markdown. Images, PDFs, data files such as CSV / JSON / YAML / XML, common source files such as Python / Go / TypeScript / SQL, and zip / tar.gz archives can all be published to the gallery now, and cards show a matching icon per type.

Get started

Go to Flashduty console → AI SRE → Artifacts, open any artifact, and click Share in the top right.

For details, see the product documentation.

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

Troubleshooting keeps coming back to one question: what is this machine actually talking to? The dependencies drawn in an architecture diagram and the ones that exist in production right now are rarely the same thing — a service is retired but stays on the diagram, a new call is added and nobody updates it, and after containers move around it stops matching entirely. So you end up on the host, reading connections one at a time.

ServiceMap (Beta) takes a different route: instead of relying on a hand-maintained diagram, it builds the dependency topology among hosts, processes, containers, and workloads directly from the real network connections monit-agent observes through eBPF. It shows what is communicating right now, not what the documentation says should be.

Turning "a connection" into "a service dependency"

The raw fact the Agent observes is "this process connected to this ip:port". ServiceMap matches that target endpoint against known listeners within the same network scope to recover a service-level dependency, and labels how much you can trust it: a unique match is Confirmed; a match against several possible counterparts is Candidate, which you resolve with context; an endpoint that matches no listener is Unresolved and stays off the canvas by default, so external addresses and short-lived connections don't bury the real dependencies.

On the canvas you can filter by resolution status, adjust the upstream and downstream hop range, and double-click any node to focus on just its neighborhood. Open a node or a dependency and the side panel gives you entity identity, executable, container and workload, target endpoint, resolution reason, candidate count, and confidence — these are exactly what tells you whether a dependency is trustworthy.

Unresolved connections aren't hidden

Endpoints with no matching counterpart are grouped by reason in their own panel, filterable by endpoint or source service, and exportable to CSV for offline reconciliation. From there you can also locate the source, jumping back to the canvas with the originating entity highlighted.

It tells you how much to trust the picture first

A topology is built from evidence within a recent observation window — it is not a live snapshot and it is not guaranteed to be complete. So the query info explicitly reports the capture mode, evidence freshness, the projection state of the listener inventory and Kubernetes metadata enrichment, and whether this query hit any truncation. If freshness isn't fresh, or a truncation notice appears, the graph can't be read as a complete real-time dependency set — showing you the basis for that judgment is more useful than handing you a graph that merely looks certain.

Get started

Go to Flashduty console → Monitors → Monitoring objects and click Topology on a host row, or use ServiceMap Hosts in the toolbar to browse every reporting host.

ServiceMap is in beta, so its behavior and interface may still change. It relies on monit-agent's eBPF observation — if the Agent is too old, the runtime doesn't support it, or ServiceMap isn't enabled, there is no topology data.

For details, see the product documentation.

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. For how this is built, why the agent runs real kubectl and why your cluster dials out to us instead of opening a port, see Safe cluster access for AI SRE.

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.