Alert Routing
Route alerts to the right escalation policy or channel based on status, project, or check.
Alert Routing decides where an alert goes the moment something changes. You create routing policies that match alerts on conditions like status, project, or a specific check or job, and then send matching alerts to an escalation policy or straight to a channel.
Routing, Escalation Policies, and Channels are three different layers
It's easy to mix these three up, so here's the distinction:
- Alert Routing (this page) is the decision layer. It answers "when THIS kind of alert fires, who should be told?" by matching conditions to a destination.
- Escalation Policies are the chain of people routing hands off to — step 1 pages the primary on-call, step 2 pages the backup after a few minutes, and so on.
- Channels are the actual connections used to deliver a message — a specific Slack channel, an email list, and similar.
Example: route CRITICAL incidents on the Payments project to the On-Call escalation policy, so the chain of on-call engineers gets paged in order. Route everything else to the #eng-alerts Slack channel, so the team stays aware without anyone getting paged. Alert Routing is the rule that makes that split; the escalation policy and the channel are just the destinations it points to.
How a rule decides what "matches"
Every routing policy is made up of one or more rules, and each rule has its own match conditions:
- Match Status — choose one or more of Down, Late, or Recovery. This is the trigger: for example, only route when a check goes Down, or also route the Recovery notice once it comes back.
- Filter by Project (optional) — narrow the rule to one or more specific projects. Leave it empty to match checks and jobs in any project.
- Filter by Check (optional) — narrow the rule to one or more specific checks. Leave it empty to match any check that fits the other conditions. This filter only covers checks, not jobs.
A rule with no project or check filter, just a status, acts as a catch-all for that status — useful as a fallback at the bottom of a policy.
What a rule does when it matches (Actions)
Each rule has one or more actions — what actually happens once the conditions match. There are three types:
Sends the alert to one or more channels you pick — a Slack channel, an email list, or any other channel you've connected. This is the "post it somewhere visible" option; nobody is individually paged.
Sends the alert directly to specific Users, Teams, or On-Call Schedules you choose. Selecting a team or schedule notifies everyone on it (or whoever is currently on call) without you having to name individuals one by one.
Hands the incident off to a single Escalation Policy. This is the option to reach for whenever an alert needs a guaranteed, ordered response — the policy handles paging the right person and escalating if nobody acknowledges in time.
Every action also has two throttling settings, so a flapping check doesn't spam your team:
- Max Dispatches — the most times this action will fire per check (1–10) before it stops. It resets once the check recovers.
- Cooldown (seconds) — the minimum time to wait between dispatches of this action.
Creating a routing policy
Open Alert Routing
Go to Alerting > Alert Routing in the sidebar. If you already have policies, click Create Policy in the top right. If this is your first policy, use the quick-start form on the empty state — give it a name and click Continue to builder to jump straight into the same editor.
Set the policy details
In the General section, give the policy a name and, optionally, a description. Set its Priority — lower numbers are evaluated first (see below for why this matters). Leave Enabled on so the policy is actually used.
Add a rule
Switch to the Rules section and click Add rule. Choose which statuses to match (Down, Late, Recovery), and optionally narrow it to specific projects or checks.
Add an action
Inside the rule, click Add Action and pick a destination: Send to Channels, Notify People, or Trigger Escalation. Fill in the targets for whichever type you picked, and adjust Max Dispatches and Cooldown if the defaults don't fit. Add more rules or actions if you need more than one match condition or destination.
Save
Click Create Policy (or Save Policy when editing) to apply it. New alerts are evaluated against it immediately.
Managing existing policies
The Alert Routing list shows every policy with its Priority, how many Rules and Actions it has, and whether it's Active or Disabled. Use the All / Active / Disabled tabs and the search box to find a policy. Click the Name, Priority, or Status column header to sort by that column.
Click anywhere on a row (or use the ⋯ menu) to Edit it, which reopens the same drawer used to create it. Choose Delete from that menu to permanently remove a policy and all its rules — you'll be asked to confirm first, since this can't be undone.
Only the first matching rule fires
Policies are evaluated in priority order (lowest number first), and rules inside a policy are evaluated top to bottom. As soon as one rule matches, its actions run and evaluation stops — later policies and rules are not also triggered for that alert.
This is why priority matters: put your most specific policies (e.g. "Payments project, Down") at a lower priority number than your general catch-all policy, or the catch-all will win first and your specific rule will never get a chance to match.
If nothing matches
If no enabled policy has a rule that matches an alert, Ionhour falls back to notifying every channel connected to your workspace. Add a catch-all rule (a status match with no project or check filter) at the end of your lowest-priority policy if you want full control over where unmatched alerts go instead.
Next Steps
Escalation Policies
Build the on-call chains that Trigger Escalation actions hand off to.
Channels
Connect Slack, email, and other destinations that routing rules can send to.
Notifications
Understand personal and workspace notification preferences that apply on top of routing.
API Reference
Programmatic access to Ionhour.