Automations

Private beta: AI SRE is currently in private beta. Pro or higher accounts can apply for free beta access through the AI SRE private beta application form; after approval, Flashduty will add your account to the whitelist. Features and the UI may change during the beta.

Overview

An automation lets AI SRE run a hidden session on a cadence you set. The session does not appear in the session list in the left sidebar of the console; instead it runs in the background, driven by a fixed task prompt, to have the agent complete its work and produce results such as routine inspections, operational insights, or incident post-mortems. Each automation is a rule. A rule carries at least one trigger:

Schedule (cron): set the cadence with a 4-field or 5-field cron expression (for example, every Monday morning or every day at 09:15); it runs automatically when the time comes.
Call via API: generate a trigger URL with a Bearer token, and trigger it on demand from an external system with a POST, passing the context for this run in the request body.

When to use it: hand recurring routine inspections (such as a daily health check) and periodic insight / post-mortem reports to AI SRE to run automatically; or wire AI SRE into your existing pipeline / change system so an external call kicks off a diagnosis when an event occurs. Entry point: AI SRE → Automations in the left navigation, route /ai-sre/automations.

Every run produced by an automation is, at its core, still an AI SRE session — it is simply marked as hidden and not mixed into your everyday session list. You can always click into it from the run history to see the full conversation, tool calls, and artifacts of that run.

Creating an Automation

Click New Automation in the upper-right corner of the page to open a start panel that offers two entry points:

Start from scratch

Choose Start from scratch to open a blank form and manually fill in the name, task prompt, and triggers. This suits cases where you already know what you want the agent to do and want a fully custom prompt.

From a preset template

Below, a set of preset template cards is listed (delivered by the backend per UI language: zh-CN for Chinese, en-US for English). Common ones include Noise Reduction, Incident Post-mortem, Escalation / Load, Change, and On-call. Click any template card to prefill the form with the template’s name and task prompt; tweak from there.

Either entry point leads to the same configuration form.

Configuration Fields

The configuration form has the following fields:

Field	Required	Notes
Name	Yes	The rule name, up to 255 characters. Placeholder example: `Weekly on-call insight`.
Scope	Yes	Use the scope selector to choose Personal (`team_id=0`) or a Team (`team_id>0`). Scope determines both the rule’s ownership and edit permissions, and constrains the self-hosted Runners selectable in Environment — only account-global Runners and Runners belonging to the same team as the scope are selectable.
Environment	No	Use the environment picker to choose the runtime environment: Auto (the backend picks the best available environment, the default), Cloud Sandbox, or a self-hosted (BYOC) Runner. After picking a team scope, a team Runner that does not belong to that scope is cleared automatically.
Task prompt	Yes	Describe the task for AI SRE to perform, written in a rich-text editor. This prompt is exactly what is sent to the agent on each run. Placeholder: `Describe the task for Flashduty AI SRE to perform.`

For Environment, “Auto” has the backend pick the best available environment at each run; “Cloud Sandbox” is a platform-managed ephemeral sandbox; a self-hosted Runner runs on your own machine. See Environments for the differences and how to connect them.

Triggers

A rule must have at least one trigger configured. In the “Triggers” section of the form, click Add trigger to choose between two kinds; both can be enabled at the same time.

Schedule (cron)

Runs automatically on a time cadence. The cadence supports two cron forms:

4 fields: hour day-of-month month day-of-week; the system adds minute=0, suitable for top-of-hour tasks.
5 fields: minute hour day-of-month month day-of-week, suitable for minute-level tasks. For example, 15 9 * * * means every day at 09:15.

6-field cron expressions with seconds are not supported. The minute must be one fixed integer; other fields support only the simple forms below:

Segment	Allowed values
Minute (5-field only)	A fixed integer from `0` to `59`
Hour	``, `/n` (`n` from 1 to 23), or one fixed integer from `0` to `23`
Day of month	`*` or `1`–`31`
Month	`*` or `1`–`12`
Day of week	`*` or `0`–`7` (both `0` and `7` mean Sunday)

To avoid hand-writing the expression, the UI offers four modes:

Mode	Meaning
Hourly	Runs once per hour; defaults to the top of the hour, and can also use a fixed minute
Daily	Pick a time; runs at that time every day
Weekly	Pick a weekday + time; runs at that time each week
Custom	Type a 4-field or 5-field cron expression directly

Time zone: in Daily / Weekly modes, the time you pick is interpreted in your local time zone, converted to UTC on save; the UI labels your local time zone next to the cadence summary. In Custom mode the expression is interpreted in UTC, labeled UTC in the UI.

The actual execution time may differ from the set time by a few minutes. This is intentional, to spread out system load. Do not treat a rule as a second-accurate timer.

Call via API (HTTP POST)

Lets you trigger this automation on demand from an external system, independent of a time cadence.

Enable and save

Add Call via API under “Triggers” and save the rule. On a successful save, the system generates a one-time Token and trigger URL for triggering, and opens a dialog containing a curl example.

Save the Token

The Token is shown only once: copy and save it immediately. After you close the dialog you cannot view it again — you can only regenerate (rotate) a new one, and regenerating invalidates the old Token.

Trigger externally

Call the trigger URL with POST, placing the Token in the Authorization: Bearer header, and pass the context for this run in the text field of the request body. The curl example shown in the dialog looks like:

curl -X POST 'https://<trigger-url>' \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{"text":"Describe the event or context for this run."}'

The text in the request body is passed to the agent as context for this run, on top of the task prompt configured on the rule. The optional dedup_key provides idempotency: the same trigger with the same dedup_key reuses the same run.

A rule can enable both “Schedule” and “Call via API” at the same time: it runs automatically on the cadence and can also be kicked off on demand from outside. Each trigger occupies its own row and can be removed independently.

Run History

Every rule keeps its run history. Click the History icon in the Actions column of the rule row to open it (the standalone route is /ai-sre/automations/:ruleId/history). Run history is shown as a table with these columns:

Column	Notes
Started at	The start time of the run
Duration	How long the run took
Status	The status of the run (see the table below)

Run status values:

Status	Meaning
`running`	Running
`retrying`	Retrying
`succeeded`	Succeeded
`partial`	Partially succeeded
`failed`	Failed
`skipped`	Skipped
`abandoned`	Abandoned (terminated by the system after running too long without completing)

Two filters are available above the table:

Time range: defaults to the last 30 days, adjustable, with a maximum span of 180 days.
Status: filter by the run statuses above, or choose All statuses.

Click any row to jump to the chat page of the hidden session for that run (chat?session_id=<sessionID>), where you can view the full messages, tool calls, and artifacts of that run. The run-history inspector’s title reads “Execution history for over the last 180 days.”

Run history is only visible for rules you can edit. For read-only rules (can_edit=false), the history entry is disabled, and opening it shows “Run history is not available for read-only automations.”

Management and Permissions

Enable / Disable, Edit, and Delete

Each rule offers a set of actions in the Actions column:

Action	Notes
Enable / Disable	An inline switch. When disabled, the rule is kept but no longer triggers; disabling does not delete existing run history.
History	Opens the rule’s run history.
Edit	Opens the configuration form to modify the rule.
Delete	Deletes the rule, with a confirmation that reads “The rule will no longer be triggered after deletion. Existing run history is cleaned up automatically after the retention period.”

For read-only rules you cannot edit (can_edit=false), the switch and all action buttons are disabled; opening its form shows “Read-only — you can view this automation but cannot edit it.” at the top. Above the list there are also two filters: Scope (All / Personal / Team, where selecting “Team” lets you multi-select specific teams) and Status (All statuses / Enabled / Disabled).

Scope and Permissions

Automation rules share the same two-level scope model as the other resources under Customize (Skills, Knowledge, MCP, Agents, Environments):

Dimension	Rule
Ownership	Personal rules (`team_id=0`) belong to their creator; team rules (`team_id>0`) belong to that team. Any account member may create an automation for any team in the current account; the creator does not need to belong to that team. After creation, the personal / team scope is immutable.
Visibility / list	The account Owner and admins see all rules; ordinary members see rules they created and rules of teams they belong to.
Edit / manage	The account Owner and admins can manage any rule; ordinary members can manage rules they created and rules of teams they belong to (enable / disable, edit, delete).
HTTP POST trigger	When initiating a real run through the trigger URL, authorization is only the trigger’s Bearer Token. Any external system holding that Token can trigger the rule, and the run creates a hidden session under the rule’s personal or team scope.

The account is the only security perimeter at runtime; the team is an ownership / editing tag. Automation rule visibility and management follow this model. For the full rules shared with the other Customize resources, see the “Scope” section on each resource page.

Console

Learn how a session holds one complete conversation — every run produced by an automation is, at its core, a hidden session.

Environments

Learn the differences between Auto, Cloud Sandbox, and self-hosted Runners, and how to pick an environment for an automation.

Usage Insights

Generate team incident-handling and operational insights from session data — a good output target for a scheduled automation.

Manage Knowledge

Provide domain knowledge to automation runs, loaded by team scope.

Quick Start

Chat

Plugins

Knowledge

Environments

Overview

Creating an Automation

Configuration Fields

Triggers

Schedule (cron)

Call via API (HTTP POST)

Run History

Management and Permissions

Enable / Disable, Edit, and Delete

Scope and Permissions

Console

Environments

Usage Insights

Manage Knowledge

​Overview

​Creating an Automation

​Configuration Fields

​Triggers

​Schedule (cron)

​Call via API (HTTP POST)

​Run History

​Management and Permissions

​Enable / Disable, Edit, and Delete

​Scope and Permissions

​Related Pages

Console

Environments

Usage Insights

Manage Knowledge

Overview

Creating an Automation

Configuration Fields

Triggers

Schedule (cron)

Call via API (HTTP POST)

Run History

Management and Permissions

Enable / Disable, Edit, and Delete

Scope and Permissions

Related Pages