Skip to main content
Private beta: AI SRE is currently in private beta and available to invited accounts only. To join the whitelist test, contact the Flashduty sales team to request access; 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-segment cron expression (for example, every Monday morning or a fixed hour each day); 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:
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. 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 is expressed as a 4-segment cron, following standard cron order with the “minute” segment dropped: hour, day-of-month, month, day-of-week (there is no minute segment). Each segment supports only * or a single fixed number:
SegmentAllowed values
Hour* or 0–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 at the top of every hour (cron * * * *)
DailyPick an hour; runs at that hour every day
WeeklyPick a weekday + hour; runs at that time each week
CustomType the 4-segment cron expression directly
Time zone: in Daily / Weekly modes, the hour 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. Hourly involves no specific hour, so no time zone is labeled.
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.
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:
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.
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.”
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, and when creating / reassigning a rule into a team, the rule’s owner must be a member of that team.
Visibility / listThe account Owner and admins see all rules; ordinary members see account-scope rules plus rules of teams they belong to.
Edit / manageThe account Owner and admins can manage any rule; ordinary members can only manage rules of teams they belong to (enable / disable, edit, delete).
Manual real runWhen initiating a real run via the trigger URL, only the rule owner or an account admin is allowed to trigger it.
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.