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

​
Prerequisites

1

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

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.
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.
Select Save.
3

(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.
4

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

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