Skip to main content
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.

​
Outcomes

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: 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

Configure a routing policy

A step-by-step guide to editing rules and assigning a policy to an integration.