Skip to main content
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.
  • On-call incident trigger: select the On-call channels and severities to watch, then start a diagnostic run when a matching incident appears.
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, or On-call incident flow so an event kicks off a diagnosis. 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:
1

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.
2

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:
FieldRequiredNotes
NameYesThe rule name, up to 255 characters. Placeholder example: Weekly on-call insight.
ScopeYesUse 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.
EnvironmentNoUse 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 promptYesDescribe 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. The current console form exposes Schedule, Call via API, and On-call incident in the “Triggers” section, and all three 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:
SegmentAllowed 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:
ModeMeaning
HourlyRuns once per hour; defaults to the top of the hour, and can also use a fixed minute
DailyPick a time; runs at that time every day
WeeklyPick a weekday + time; runs at that time each week
CustomType 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.
1

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.
2

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.
3

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.

​
On-call Incident Trigger

Add the On-call incident trigger when you want AI SRE to start automatically from On-call incidents. The trigger registers a subscription with the On-call side, and only incidents matching the selected channels and severities start a run.
1

Add the trigger

Click the On-call incident card in “Triggers”. The form expands channel and severity conditions.
2

Select channels

Select the On-call channels to watch in the Channel dropdown. Personal-scope rules can select visible account channels; team-scope rules narrow the channel list to the selected team.
3

Select severities

Select one or more severities from Critical, Warning, and Info. When this trigger is enabled, at least one channel and one severity are required.
If you create or update a rule through the API, use these fields:
FieldTypeNotes
oncall_incident_trigger_enabledbooleanWhether the On-call incident trigger is enabled.
oncall_incident_channel_idsint64[]On-call channel IDs to watch. Creating or enabling this trigger requires at least one valid ID.
oncall_incident_severitiesstring[]Incident severities to watch. Supported values are Critical, Warning, and Info; creating or enabling this trigger requires at least one value.
When a matching event arrives, the system creates a run with trigger_kind: "oncall_incident" and passes event context such as incident_id, channel_id, and severity into the session. The same trigger and the same incident_id reuse the same run, avoiding duplicate hidden sessions for one incident.

​
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:
ColumnNotes
Started atThe start time of the run
DurationHow long the run took
StatusThe status of the run (see the table below)
Run status values:
StatusMeaning
runningRunning
retryingRetrying
succeededSucceeded
partialPartially succeeded
failedFailed
skippedSkipped
abandonedAbandoned (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.
Run records returned by the API also include trigger_kind, which can be schedule, manual, http_post, oncall_incident, or debug. manual means the run was started through the run-now API, and oncall_incident means it was started by a matching On-call incident event. 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:
ActionNotes
Enable / DisableAn inline switch. When disabled, the rule is kept but no longer triggers; disabling does not delete existing run history.
HistoryOpens the rule’s run history.
EditOpens the configuration form to modify the rule.
DeleteDeletes 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.”
Run nowStarts one real run manually from the rule row. The action performs preflight checks first, then creates a hidden session for the run. Manual runs are limited to one per rule per minute.
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):
DimensionRule
OwnershipPersonal 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 / listThe account Owner and admins see all rules; ordinary members see rules they created and rules of teams they belong to.
Edit / manageThe 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 triggerWhen 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.
On-call incident triggerStarted by a registered incident subscription, not by an HTTP POST Bearer token. The run still 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.