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

> Edit a routing policy's per-severity rules, choose an escalation policy for paging outcomes, and assign the policy to an integration so each source routes the way you want.

A routing policy decides what each alert severity does when it arrives from an integration — open an incident, raise a provisional page, post a notification, or drop it — and which escalation policy pages. This guide walks through editing the rules and pointing an integration at a policy. For the concepts behind it, see [Routing policies](/concepts/routing-policies).

## Prerequisites

* At least one [escalation policy](/guides/configure-escalation-policy), if you want a paging outcome to notify a specific policy.
* At least one integration — an [inbound webhook](/integrations/inbound-webhooks) or [AWS CloudWatch](/integrations/aws-cloudwatch) source — sending alerts.

<Steps>
  <Step title="Open Routing Policies">
    In the app, open **Routing Policies** from the sidebar. You'll see your organization's **default** policy and any named policies you've created. The default policy ships pre-configured to reproduce scaling.cloud's standard behavior:

    | Severity   | Outcome          |
    | ---------- | ---------------- |
    | `critical` | Incident         |
    | `high`     | Provisional Page |
    | `medium`   | Notification     |
    | `low`      | Notification     |
  </Step>

  <Step title="Edit the per-severity rules">
    Choose a policy and select **Edit rules**. For each of the four severities, pick an **outcome**:

    * **Incident** — open an incident (and page, if an escalation policy resolves).
    * **Provisional Page** — page now; promote to an incident if unacknowledged.
    * **Notification** — post to the integration's connected channel only.
    * **Drop** — record the alert but page no one and post nothing.

    For the two paging outcomes (**Incident** and **Provisional Page**), choose the **escalation policy** to notify, or leave it on **Use the component default** to fall back to the escalation policy of the component the integration is mapped to.

    <Note>
      If you leave a paging rule on **Use the component default**, you'll see an advisory that it relies on the component's own escalation policy. That's fine — just make sure the mapped component has an escalation policy, or that alert will be rejected at ingest rather than paging no one.
    </Note>

    Select **Save**.
  </Step>

  <Step title="(Optional) Create a named policy for one source">
    If a particular source should route differently — say a noisy staging environment — select **Create policy**, give it a name like "Staging routing", and edit its rules (for example, set `low` and `medium` to **Drop**). A new policy starts from the default mapping, so you only change what you need.

    Everything that doesn't point at this named policy keeps following your organization default.
  </Step>

  <Step title="Assign the policy to an integration">
    Open the integration whose alerts you want to route — for an inbound webhook, edit it under **Settings → Integrations**. Use the **Routing policy** field:

    * Leave it on **the organization default** to follow your default policy.
    * Or pick a named policy to pin this source to it.

    Save the integration. From now on, alerts from that source resolve their outcome and paging destination through the policy you assigned.

    <Note>
      AWS CloudWatch integrations follow your organization's default routing policy. To change how CloudWatch alarms route by severity, edit the default policy in step 2.
    </Note>
  </Step>
</Steps>

## Examples

### Promote high-severity alerts straight to incidents

Edit the rule for `high` and change its outcome from **Provisional Page** to **Incident**, then choose the escalation policy that should page. `high` alerts now open an incident immediately instead of waiting for the provisional-page promotion.

### Silence a noisy low-severity source

Create a named policy for that source and set `low` (and optionally `medium`) to **Drop**, then assign the policy to the integration. Those alerts are still recorded for audit and de-duplication, but page no one and post nothing.

### Route critical and high to different teams

On one policy, point `critical` at your production on-call escalation policy and `high` at a secondary team's escalation policy. Each severity now pages its own responders.

## Notes

* The default policy can be edited but never deleted — it's the fallback every integration relies on.
* You can delete a named policy even while integrations use it; those integrations revert to the organization default.
* Any organization member can create and edit routing policies.