> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Automation rules

> Declarative when → then rules that run an action on incident lifecycle events — no AI, no approval step. Available on every plan.

An **automation rule** runs an action automatically when something happens to an incident — *"when a `critical` incident opens, post to `#major-incidents` and file a ticket"*. Rules are **declarative** and human-configured: you define `when → then`, and scaling.cloud fires the action every time the condition matches. No AI is involved, and there is no approval step — that is the difference from a [proposed action](/concepts/proposed-actions).

Automation rules are available on **every plan**, including Free.

## When → then

A rule has three parts:

| Part              | Options                                                                                                                                                           |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **When** (event)  | `incident.created`, `incident.acknowledged`, or `incident.resolved`.                                                                                              |
| **Conditions**    | Zero or more equality checks on the incident. An empty list matches **every** incident.                                                                           |
| **Then** (action) | One action to run — the same set as [proposed actions](/concepts/proposed-actions#action-types): post to channel, create ticket, attach runbook, or call webhook. |

### Conditions

Conditions are simple **equality** checks, mirroring the attributes you already match on in [routing selectors](/concepts/routing-policies):

* `severity` equals one of `critical`, `high`, `medium`, `low`.
* `component` equals one of the incident's affected components.

All conditions must hold for the rule to fire (logical **AND**). There are no ranges, `OR`, or negation — keeping rules flat and predictable, just like routing and escalation. Leave conditions empty to act on every incident for that event.

<Note>
  An action that an automation rule fires is attributed to the **rule's author**,
  not to whoever happened to acknowledge or resolve the incident.
</Note>

## Managing rules

Create and manage rules in the dashboard under **Automation Rules**. Each rule has a name, an enabled toggle, its `when` event, its conditions, and its action. Disable a rule to stop it firing without deleting it.

See [Create an automation rule](/guides/create-automation-rule) for a walkthrough.

## API

Rules are also managed over the `/v1` API:

| Method   | Path                        | Purpose          |
| -------- | --------------------------- | ---------------- |
| `GET`    | `/v1/automation/rules`      | List your rules. |
| `POST`   | `/v1/automation/rules`      | Create a rule.   |
| `GET`    | `/v1/automation/rules/{id}` | Fetch one rule.  |
| `PUT`    | `/v1/automation/rules/{id}` | Update a rule.   |
| `DELETE` | `/v1/automation/rules/{id}` | Delete a rule.   |

Authenticate with an API key as described in [Authentication](/authentication).

## Rules vs. proposed actions

Both fire the same action types, but they are reached differently:

|             | Automation rule                 | [Proposed action](/concepts/proposed-actions) |
| ----------- | ------------------------------- | --------------------------------------------- |
| **Trigger** | A lifecycle event you configure | An AI finding                                 |
| **Decides** | A condition you wrote           | A human, by approving                         |
| **Plan**    | Every plan                      | Pro / Enterprise                              |