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

# Configure Escalation

> Create an escalation policy in the dashboard, add layers with acknowledgment timeouts, and reorder them so incidents page the right responders in the right order.

An escalation policy defines the chain of responders that scaling.cloud notifies when an incident is opened. Each layer targets an on-call schedule (or a specific set of users) and has an acknowledgment timeout. If no one on that layer acknowledges within the timeout, scaling.cloud moves to the next layer.

<Tip>
  Managing policies from a script or pipeline instead? See the [Escalation policies API](/developers/escalation-api) guide.
</Tip>

## Prerequisites

* At least one on-call schedule. See [Set Up On-call](/guides/set-up-oncall-schedule) if you haven't created one yet.

<Steps>
  <Step title="Create a policy">
    Go to **Escalation Policies** in the dashboard (`/escalation-policies`) and click **Create Policy**. In the **Create Escalation Policy** dialog, give it a **Name** (e.g. *Platform Default*) and an optional **Description**, then click **Save Policy**. scaling.cloud opens the policy's detail page, where you add layers.
  </Step>

  <Step title="Add escalation layers">
    On the policy detail page, click **Add Layer** and configure the **Add Escalation Layer** dialog:

    * **Acknowledgment Timeout (minutes)** — how long this layer has to acknowledge before escalation moves on (1 minute to 1 week).
    * **Target Type** — **On-call Schedule** or **Specific Users**.
      * For **On-call Schedule**, pick the schedule from the dropdown.
      * For **Specific Users**, check the team members to notify.

    Click **Save Layer**. Add a first layer targeting your primary schedule with a short timeout (e.g. 5 minutes), then a second layer targeting a backup schedule or a manager with a longer timeout.

    <Note>
      If no one acknowledges within a layer's timeout, scaling.cloud notifies the next layer automatically. If all layers are exhausted without an acknowledgment, escalation stops but the incident stays open. Make sure your final layer targets a reliable fallback.
    </Note>

    <Tip>
      To gate a layer by time of day — page one team during their working hours and another otherwise — set its **Working Hours Condition**. See [Follow-the-sun escalation](/guides/follow-the-sun-escalation).
    </Tip>
  </Step>

  <Step title="Order the layers">
    Layers fire top to bottom. Use the **Move layer up** / **Move layer down** controls on each layer card to set the escalation order — the first layer is paged first, and each subsequent layer fires only if the one before it times out.
  </Step>

  <Step title="Page the policy from an incident">
    An escalation policy pages responders when it's attached to an incident. The simplest path is to point a layer at an on-call schedule and then select that schedule as the **On-call lead** when you [create an incident](/guides/create-first-incident) — paging follows the policy attached to that schedule. You can also check the **Who would be paged right now** preview on the policy detail page to confirm the chain resolves the way you expect.
  </Step>
</Steps>

## Next steps

<CardGroup cols={2}>
  <Card title="Follow-the-sun escalation" href="/guides/follow-the-sun-escalation" icon="globe">
    Gate layers with working-hours conditions so a page reaches whoever is awake.
  </Card>

  <Card title="Configure Routing" href="/guides/configure-routing-policy" icon="route">
    Route inbound alerts to the right escalation policy automatically.
  </Card>
</CardGroup>