> ## 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.
# Routing Policies
> Decide what happens to an incoming alert based on its severity — open an incident, raise a provisional page, post a notification, or drop it — and which escalation policy pages.
A routing policy controls what scaling.cloud does when an alert arrives from an integration. For each **severity** — `critical`, `high`, `medium`, and `low` — the policy decides two things:
* **The outcome** — whether the alert opens an incident, raises a provisional page, posts a notification, or is dropped.
* **Where it pages** — for outcomes that page, which escalation policy is notified.
A routing policy is a named, reusable object you define once and point many integrations at. It is the outer envelope that *composes* escalation policies — it doesn't replace them. The escalation policy still defines the ladder of responders; the routing policy decides which severities reach that ladder, and how.
Routing policies apply only to alerts that arrive from an integration (an inbound webhook or an AWS CloudWatch source). Incidents you create manually are unaffected — when you open an incident yourself, you are the router.
## The four routing rules
Every routing policy has exactly four rules, one per severity. Each rule has an outcome, and — for paging outcomes — an optional escalation policy.
| Severity | Outcome | Escalation policy |
| ---------- | ---------------- | --------------------- |
| `critical` | Incident | Pages a chosen policy |
| `high` | Provisional Page | Pages a chosen policy |
| `medium` | Notification | — |
| `low` | Notification | — |
### Outcomes
| Outcome | What happens |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Incident** | Opens an incident. If an escalation policy resolves, it pages that policy; if none resolves, the incident still opens with no auto-page. |
| **Provisional Page** | Pages immediately and, if no one acknowledges in time, promotes to an incident. |
| **Notification** | Posts a notification to the integration's connected channel — no incident, no page. |
| **Drop** | Records the alert for audit and de-duplication, but produces no incident, page, or message. |
Use **Drop** to silence a noisy low-severity source without losing the audit trail. A dropped alert is still recorded, so a later "resolved" signal from the same source correlates correctly.
Only the two **paging** outcomes — Incident and Provisional Page — can carry an escalation policy. Notification and Drop never page.
## How a policy is selected
When an alert arrives, scaling.cloud resolves the policy in two steps:
1. **Which policy applies** — the routing policy assigned to the integration the alert came from. If the integration has no policy assigned, your organization's **default routing policy** is used.
2. **Which escalation policy pages** — for a paging outcome, the escalation policy named on the rule. If the rule leaves it blank, the alert falls back to the **component's** default escalation policy.
Routing policies are assigned to **integrations**, not to components. There is no per-component routing policy. A component only contributes its own escalation policy as the final paging fallback when a rule doesn't name one — it never changes which outcome a severity produces.
## The default routing policy
Every organization starts with one default routing policy that reproduces scaling.cloud's standard behavior, so nothing changes until you deliberately edit it:
| Severity | Outcome |
| ---------- | ---------------- |
| `critical` | Incident |
| `high` | Provisional Page |
| `medium` | Notification |
| `low` | Notification |
The default policy is **editable** — change it to adjust org-wide routing — but it can **never be deleted**, because it is the fallback every integration relies on.
## Choosing an escalation policy per severity
For a paging outcome, you can name the escalation policy that should be notified, or leave it on **Use the component default**. When left on the default, the alert pages the escalation policy of the component the integration is mapped to.
This lets one routing policy serve many integrations whose components differ: `critical` can simply mean "page this component's own on-call" without naming a specific policy.
When you save a paging rule with no escalation policy chosen, you'll see an advisory that it relies on the component's default. That's allowed — but if, at the time an alert arrives, the component has no escalation policy either, the alert is handled as described below.
## What happens when a page can't resolve
scaling.cloud never silently drops a page:
* A **Provisional Page** rule that resolves to no escalation policy (neither on the rule nor on the component) is **rejected and recorded**, so an unhandled `high` alert can never vanish unnoticed.
* An **Incident** rule that resolves to no escalation policy still **opens the incident** — it simply doesn't auto-page. This preserves the safe, tolerant behavior for incident creation.
## Reusing and managing policies
Manage your policies on the **Routing Policies** page:
* **Create** a named policy (for example, "Production routing") and point specific integrations at it, while everything else follows the org default.
* **Edit** any policy's four severity rules at any time.
* **Delete** a custom policy even if integrations are using it — those integrations gracefully revert to the org default. The default policy itself cannot be deleted.
Any organization member can create and edit routing policies — deliberate configuration is the guardrail, not a role gate (the same model as escalation policies).
## Next steps
A step-by-step guide to editing rules and assigning a policy to an integration.