> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Automations
> Have AI SRE run a hidden session automatically on a cron schedule, through an HTTP API, or from an On-call incident event, driven by a task prompt, to produce inspection, insight, or post-mortem results. This page covers creating automation rules, configuration fields, triggers, run history, and permissions.
**Public beta**: AI SRE is now open to all accounts — no application needed. Sign in to the console and start using it; it's free during the public beta. Features and the UI may continue to evolve.
## 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
***
The page header offers two creation entry points: an outline-style **Create via chat** button that jumps to the chat page with a prefilled prompt — "Let's create an automation task. First explain how automation tasks work. Then ask me questions to figure out what task I need to schedule and when it should run." — letting the agent work out the task content and trigger through conversation, skipping the form; and a primary-style **Create** button that opens a start panel with two entry points:
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.
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 **Weekly Insights**, **Alert Governance**, **On-call Incident Analysis**, and **On-call Load Analysis**. 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. 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:
| 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.
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.
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.
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:
```bash theme={null}
curl -X POST 'https://' \
-H 'Authorization: Bearer ' \
-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.
On success, `data` returns the new hidden session. Save `session_id`, or use `session_url` to open the full conversation, tool calls, and artifacts for this run:
```json theme={null}
{
"data": {
"type": "routine_fire",
"session_id": "",
"session_url": "https:///ai-sre/chat?session_id="
}
}
```
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.
Click the **On-call incident** card in "Triggers". The form expands channel and severity conditions.
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.
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:
| Field | Type | Notes |
| --------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `oncall_incident_trigger_enabled` | boolean | Whether the On-call incident trigger is enabled. |
| `oncall_incident_channel_ids` | int64\[] | On-call channel IDs to watch. Creating or enabling this trigger requires at least one valid ID. |
| `oncall_incident_severities` | string\[] | 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.
When the run finishes, AI SRE writes one summary comment back to the incident that triggered it: conclusion first, body kept concise, with a link to the full session at the end. The comment travels through the incident's existing notification chain (for example, incident card refreshes and thread replies in IM), so whoever is watching the incident sees the analysis without opening the console. This applies to every rule with the On-call incident trigger enabled — including rules with custom prompts — with no extra configuration.
## Run History
***
Every rule keeps its run history. Clicking anywhere on the rule row (there is no dedicated history icon) opens the rule's detail page at `/ai-sre/automations/:ruleId`: the left column shows "Configuration" and the right column shows "Run History", side by side. The right column has its own **Run now** button at the top, so you can trigger a run directly from the detail page.
Run history is shown as a table with these columns:
| Column | Notes |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | The hidden session behind this run. The backend batch-resolves each run's session title (`session_name`, the hidden session's auto-generated name); when it can't be resolved, the cell falls back to the session ID (`session_id`) |
| Started at | The start time of the run |
| Duration | How long the run took |
| Triggers | The trigger type of the run, such as `Schedule`, `HTTP POST`, `On-call incident`, or `Run manually` |
| 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) |
Three 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**.
* **Trigger type**: choose from `All trigger types` / `Run manually` / `Schedule` / `HTTP POST` / `On-call incident`.
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=`), where you can view the full messages, tool calls, and artifacts of that run.
Run history is embedded in the rule's detail page, and opening the detail page itself already requires edit permission on that rule — a rule you cannot edit cannot be opened at all (it shows "Automation rule not found or access denied"), so its run history is likewise unreachable.
## 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. |
| Run now | Starts 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. |
Clicking anywhere on the rule row opens its detail page, where you can edit the configuration, delete the rule, and view its run history (see "Run History" above).
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 AI SRE (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. **Scope is fixed at creation and cannot be changed afterward**: when editing a rule, the scope selector is disabled with the hint "Scope can't be changed after creation. To use a different one, clone this automation and pick a new scope for the copy." To switch scopes, use the **Clone** button on the rule's detail page — cloning opens a prefilled create form where you pick the new scope for the copy before saving (the update API no longer accepts `team_id`, so the scope cannot be changed even by bypassing the UI). To create a team rule, the **operator themselves** must be a real member of the target team (join-to-govern); account Owners and admins have no exemption. A team rule does not stop with its creator: even after the creator has left the team, the team carries on running the rule. Only personal rules are disabled when their Owner is no longer an active account member — the system disables the rule automatically once a trigger attempt's preflight finds the Owner inactive. |
| 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 (team rules) | Only **current members** of the rule's owning team can act on the rule (enable / disable, edit, delete, run now); once the creator has left the team, they keep no standing privilege. The account Owner and admins have no exemption and must join the team first. |
| Edit / manage (personal rules) | Only the creator can manage a personal rule. The account Owner and admins have **no** exemption for other members' personal rules — they cannot even view its detail page; opening one returns "access denied" outright, not just a grayed-out button. |
| 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. |
| On-call incident trigger | Started 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 Owner / admins can see other members' personal rules in the list (see "Visibility / list" above), but clicking into the detail page is denied — the "Edit / manage" permission is not exempted for the Owner / admins on personal rules, just as it is not on team rules.
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 AI SRE resources, see the "Scope" section on each resource page.
## Related Pages
***
Learn how a session holds one complete conversation — every run produced by an automation is, at its core, a hidden session.
Learn the differences between Auto, Cloud Sandbox, and self-hosted Runners, and how to pick an environment for an automation.
Generate team incident-handling and operational insights from session data — a good output target for a scheduled automation.
Provide domain knowledge to automation runs, loaded by team scope.
If a report from an automation run is published, it lands in the artifact gallery for long-term viewing and sharing.