Escalation policies
An escalation policy is the playbook Incido follows when it needs to reach operators about an incident: ordered steps, who each step tries to reach (a specific user or whoever is on call from a schedule), delays between steps, and what happens when someone acknowledges a notification. In the Dashboard, Escalation policies appears under On-call alongside Teams and Escalations, so routing and coverage sit in one place. Schedules are managed from each team’s view; see Teams and rosters. Steps do not pick email versus SMS themselves; channels come from each user’s notification contact methods, filtered by the incident severity’s notification urgency (high or low), so the same policy can behave differently for a minor glitch and a major outage without duplicating configuration.
Policies are organization-scoped, keyed for API and configuration export, and can be disabled or soft-deleted. A disabled policy is ignored for new runs. Soft delete keeps history intact for past escalation runs while blocking new use. On the Escalation policies list, rows are sorted by name so you can scan policies predictably; open a policy from the list to work on its view page.
Steps and recipients
You create a policy from the Escalation policies list using Add escalation policy, which opens a modal wizard. Your subscription plan caps how many steps a single policy may contain (Starter allows fewer steps than Pro or Business); there is also an absolute platform maximum per policy. When you reach your plan cap, Add step on the policy view stays visible with the same control styling; clicking it opens a modal explaining that you can upgrade your plan to add more steps (with a billing CTA when you have permission, same as other upgrade prompts in the Dashboard). When you reach the platform cap, Add step opens a modal that explains the absolute limit instead. The API rejects additional step creates in both cases. The first step collects the human-readable name, the stable key (the key is suggested from the name and you can adjust it), and assign role on acknowledge. New policies start enabled by default. The next step is routing triggers (when automatic alerting may consider this policy). The following step is match conditions: optional Simple rows or Advanced JsonLogic to narrow incidents, using the same concepts described below for automatic routing. The final wizard step is Who to notify: pick at least one team, on-call schedule, or user, and a notification strategy (notify_one or notify_all). That creates the policy’s first step with key primary and a five-minute post-step delay (you can change key and delay later when editing the step on the view page). Saving completes the wizard and opens the policy view page, where you work with steps alongside summaries of policy metadata and routing. The view uses a wide column for the ordered step chain: each step is a collapsible card you can expand to see the key, post-step delay (shown in seconds; add/edit uses whole minutes that map to seconds on save), and recipient details. Drag the grip handle on a step to reorder when there is more than one step. When at least one step exists, the chain ends with a closing node labeled Alert is marked as exhausted, connected from the last step by the same post-step delay label used between steps. A narrower column holds Policy details (key, name, description, enabled flag, acknowledgement role) and Routing (triggers and a readable summary of conditions). Use Edit policy to change the policy details in a modal, and Edit routing to change triggers and match conditions in a separate modal. From the same view you add steps with Add step at the bottom of the chain, and edit or delete each step from its card header.
Each step picks a recipient strategy: either an on-call schedule (Incido resolves the current on-call user from materialized shifts), a team (Incido resolves members from that team’s on-call setup), or specific users in the organization. Notification strategy chooses how multiple resolved recipients are paged: notify one (round-robin, one user per attempt) is available on every plan; notify all (every resolved user in parallel) requires Pro or higher. On Starter, the Dashboard still shows Notify all but disables it with a link to billing. If you downgrade from a plan that allowed notify all, you must change any step still set to notify all to notify one before the plan change completes. Delay after this step is how long Incido waits after that step’s delivery wave completes before moving on to the next step. For the last step, that same delay is the final time recipients have to acknowledge before Incido ends the run as exhausted, which makes it clear the escalation finished without a human confirmation. The Dashboard form asks for minutes; the API field is delay_after_step_seconds if you need second-level precision. Acknowledgement handling can optionally assign the acknowledging user to a responder role on the incident when you configure that on the policy.
Automatic routing (triggers and conditions)
Automatic incident escalations do not run every policy at once. Instead, each policy can opt into automatic routing by choosing one or both routing triggers: when a new incident is created, and when an incident is updated in ways that matter for alerting (severity, status, or lifecycle stage). If you leave routing triggers empty, that policy never starts an automatic run; it can still be used when an operator explicitly starts an escalation run and picks that policy. The view labels that situation as No automatic trigger so it is obvious the policy is manual-only for automatic routing.
Match conditions only apply when the policy participates in automatic routing. If you leave routing triggers empty, the Dashboard still explains that conditions are not used without a trigger, because manual escalation runs and other explicit uses of the policy do not consult that rule. Once you select at least one trigger, you can leave the expression empty to mean match all for incidents that passed the trigger filter, or narrow with Simple or Advanced rules as below.
The routing match expression is optional whenever triggers are set. When it is empty (or you clear it in the editor), Incido treats the policy as match all for incidents that already passed the trigger filter — useful for a broad “page everyone on create” policy. When you provide an expression, it must be valid JsonLogic JSON using only the operators Incido allows, and it may only reference incident fields that make sense for the triggers you selected (for example status and stage fields apply when incident updated is selected). If the expression is invalid or too large, the Dashboard rejects the save so you fix it before it can silently fail at runtime.
Most operators can stay in Simple mode: you add one or more conditions that are combined with and. Each row picks a field (only fields allowed for your selected triggers appear), an operator (One of or None of), and one or more values, laid out in three columns so field, operator, and values sit on one horizontal row per condition. Severity level and incident status use the same prefixed public ids you see elsewhere in the product (sev_… and ist_…); under the hood, JsonLogic compares the incident’s current severity or status to that set. Incident updated also lets you match on lifecycle stage (still plain stage keys). For tags, One of means the incident carries at least one of the tags you listed, and None of means it carries none of them, which matches how Incido passes the incident’s tag list into the rule engine. Incident responder role uses the same membership idea with clearer operator names: you choose one or more roles by their irr_… ids. Incident must have one of passes when the incident already has an active assignment for any of those roles (someone has accepted the role and has not been released). Incident must not have any of passes when none of those roles are active in that sense—useful when you only want to escalate while a commander slot is still empty. Both incident created and incident updated expose this signal; a brand-new incident usually has no active assignments yet, so Incident must have one of against roles will not match until someone accepts, while Incident must not have any of can still match vacuously. Advanced mode is the raw JsonLogic editor. It is available on Business (and Enterprise) plans; Starter and Pro can use Simple match conditions only. Without the advanced routing feature, the Dashboard shows the Advanced option disabled and points you to billing to upgrade. If a policy was saved with an expression that Simple mode cannot represent (for example it uses or at the top level, nesting, or patterns Simple does not emit), the form opens in Advanced only until you clear or replace that expression — this avoids silently rewriting rules you carefully authored elsewhere, including the API. On the view page, conditions that are not Simple-readable are summarized as a custom JsonLogic rule with a pointer to Edit routing for the full text.
What changes on the public frontend
Escalation policies and routing are operator configuration. Customers see the outcome only indirectly when your team responds faster because alerts reached the right people. The public status page does not list policy names or JsonLogic.
Operational effects
When no enabled policy matches an automatic routing evaluation for a given incident event, Incido does not start an automatic escalation. If you expected a page and nothing fired, start from routing: confirm at least one policy has the right trigger and an expression that can actually pass for that incident’s severity, tags, status, and stage. Incident updated routing sees a coarse “something changed” signal; very narrow expressions that assume a single field change may need revisiting.
If several policies match the same batch of events, Incido can start multiple runs (one per policy), still subject to dedupe rules that prevent duplicate open runs for the same incident, policy, and source event. When both incident created and incident updated fire in one processing batch, the first coarse event in order that causes a policy to match is what that run stores as its source event for dedupe purposes. Incido evaluates candidate policies in a stable internal order; you do not configure that order in the Dashboard.
Configuration export and import include routing fields on policies so you can move routing between environments together with the rest of on-call setup.
Troubleshooting
No automatic alert although the incident looks severe. Check that the on-call feature is enabled for the subscription, that at least one policy has routing triggers covering the situation, and that the match expression (if any) is not accidentally always false. Routing does not silently fall back to another policy when nothing matches—you must fix triggers and conditions so at least one policy can qualify.
Save fails with a routing expression error. Incido validates structure, size, allowed operators, and variable names against your selected triggers. Narrow the expression to allowed fields, remove unsupported operators, or widen triggers if you need variables that only exist on incident updated.
Several policies matched and multiple runs started. That can be intentional when different policies cover different teams or channels. Dedupe prevents duplicate open runs for the same incident, policy, and source event; it does not enforce a single policy for the whole incident.