incident.io escalation policies: how Slack-native routing simplifies on-call

TL;DR: incident.io escalation policies (called escalation paths) define who gets paged at each level, how long to wait before escalating further, and how routing shifts based on time-of-day or incident priority. You configure them once in the UI, then trigger them automatically via alert routing or manually with /incident escalate inside any Slack incident channel. The key difference from PagerDuty: the entire flow stays inside Slack, not a separate web app you have to open while production is burning.

You've set up your on-call schedule. Your Datadog alerts are firing into incident.io. But without a well-configured escalation path, our system can't determine whether to page your backend team, your database on-call, or your VP of Engineering at 3 AM. That gap costs you coordination time on every incident. For a team running 20 incidents per month, even 15 minutes of overhead per incident adds up to 5 hours lost to coordination before your engineers touch a single line of code.

This guide walks through how to configure escalation policies in incident.io from scratch, how to connect them to your Service Catalog for intelligent routing, and how staying entirely in Slack cuts the tool-switching tax that web-first platforms can't eliminate.

What you gain with escalation paths

We call our escalation policies escalation paths, and we built them to eliminate coordination tax. When an alert fires at 2 AM, the system knows whether to page your backend on-call, escalate to your database team after 5 minutes, or notify a Slack channel for a low-priority issue during business hours. That decision tree runs automatically based on three inputs: who's defined at each level, how long to wait before escalating, and routing conditions like time-of-day or incident priority.

Every escalation path you build has these three components:

• Levels: Each level pages a schedule, individual, or Slack channel. We stack levels so if Level 1 doesn't acknowledge within your time window, we automatically page Level 2.
• Time delays: You set how long we wait for acknowledgement before moving to the next level. Adjust these per severity so a high-urgency incident escalates faster than a low-urgency one.
• Routing branches: You can branch based on working hours and priority, so a high-urgency incident at 2 AM routes differently than a low-urgency incident during business hours. This prevents waking your VP of Engineering for low-urgency alerts. You also have the option to route all escalations to a shared Slack channel simultaneously, so leadership stays informed while a specific on-call engineer handles the response.

"incident.io allows to seamlessly nudge or suggest actions. You can implement your incident management framework easily... You're on a high prio incident, maybe you should escalate to get some help? Here's a simple button." - Alexandre R. on G2

How to build your first escalation path

Our on-call getting started guide identifies three prerequisites before a meaningful escalation path exists: teams, schedules, and alert routing.

Step 1: Set up teams and schedules

Configure your teams directly in incident.io, or import them via SCIM (System for Cross-domain Identity Management, the standard protocol for syncing user and team data from your identity provider to third-party tools) from your identity provider or service catalog tool. Then create at least one on-call schedule with your rotation members. Our escalation paths reference these schedules as notification targets, so they need to exist first.

Step 2: Define escalation levels and wait times

Create an escalation path and add your first level pointing at your on-call schedule. Set a wait time based on severity and your team's response expectations. Add a second level for your backup responder or team lead if the first level doesn't acknowledge in time.

We recommend adding a final level that notifies a shared Slack channel where anyone can step in. This gives you a safety net so critical alerts never go completely unacknowledged.

Step 3: Add working hours and priority branches

This is where our escalation paths pull ahead of simple paging sequences. You define named working hours sets (for example, "UK hours: Mon-Fri 09:00-17:00 GMT" and "US hours: Mon-Fri 09:00-17:00 PT") and reference them in separate branches.

A practical three-branch setup for a single escalation path:

1. High urgency + within working hours: Page on-call with high urgency, wait 10 minutes.
2. High urgency + outside working hours: Page on-call immediately, escalate to team lead after 5 minutes.
3. Low urgency + any time: Page on-call with low urgency, set a wait time that matches your team's tolerance for low-priority noise (longer than your high-urgency delay). Note: if you need different working hours applied at different levels, use separate branches. This gives you the most explicit control over routing behavior at each level.

Skip the midnight spreadsheet lookup with Service Catalog routing

Static escalation paths work well, but the real leverage comes when you connect them to our Service Catalog. When a Datadog alert fires for your payments API at 11 PM, the Catalog already knows that service maps to your backend team's escalation path. No manual lookup. No Slack DM hunting for who's on-call for the database team.

Head to the Catalog, create a type like "Features," then go to Settings and Custom fields to add a custom field (for example, "Affected Features"). Add it to your Declare form, and when someone declares an incident, we ask which features are affected and route to the correct team's escalation path automatically. The dynamic escalation guide shows the full configuration.

That overhead compounds across every incident your team handles. Configure it once, and the time savings repeat automatically, no ongoing engineering effort required.

"Organizing and structuring incidents. Hands down. You can configure the product to suit your process and priorities; once that's done, you use the product and refine iteratively." - Patrick B. on G2

The hands-on introduction to the incident.io Catalog shows how Catalog-powered routing works in practice across a live incident workflow.

Manual escalation with /inc commands

Automated escalation paths handle the majority of cases, but sometimes you need to page someone mid-incident who wasn't in the original path. We make this a single command: type /incident escalate or /incident page inside any incident channel, as documented in the escalating incidents guide.

If you've already acknowledged an escalation in that channel, we show a button to escalate to the next level on your path. Click it and you'll see a preview of who you're about to page and what notification message they'll receive before you confirm. This prevents the "oops, I just paged the CEO" mistake at 3 AM.

The escalate to the next level changelog covers this feature in detail, and the incident.io in Slack 2026 tutorial shows it in action.

How incident.io escalation differs from PagerDuty

The architectural difference matters more than any feature comparison. According to our incident.io vs. PagerDuty comparison, incident.io wakes you up, assembles your team, captures the timeline, and auto-drafts the post-mortem, all inside Slack. PagerDuty wakes you up and hands you a web UI.

That distinction changes the escalation experience in practice:

That context switch compounds across incidents. If your team handles a steady volume of incidents, those minutes add up fast. Fewer tool switches per escalation means less coordination overhead on every incident, not just the major ones. At $150 loaded engineer cost, even modest time savings per escalation add up. And according to the PagerDuty comparison, for a 50-person engineering team, incident.io costs over $12,000 less annually than PagerDuty Business with essential add-ons.

The on-call migration from PagerDuty webinar and the Debrief: introducing incident.io on-call both cover the practical differences teams experience after switching.

The blog post on PagerDuty on-call workarounds also documents how the cost of extra tool-switching steps accumulates across a month's worth of incidents.

Escalation path setup checklist

Before your first production incident runs through escalation paths:

• Teams configured in incident.io or imported via SCIM
• At least one on-call schedule created with rotation members
• Alert routing configured from Datadog, Prometheus, or your primary observability tool
• Level 1 points at your primary on-call schedule
• Level 2 points at backup responder or team lead
• Time delays set per severity expectations
• Working hours named sets created for geographic or time-based routing
• Priority-based branches configured if needed
• Shared Slack channel added as final level fallback
• Service Catalog attributes populated for your most critical services
• Test alerts sent to validate routing hits the correct schedule (disable escalations in the alert route during testing per the getting started guide)
• /incident escalate verified in a demo incident channel

If you manage policies as code, the escalation paths API v2 exposes full create, read, update, and delete operations for Terraform and CI-driven workflows.

Schedule a demo to see the escalation path builder and Catalog routing in action.

Key terms glossary

Escalation path: incident.io's term for an escalation policy. It defines who gets paged at each level (a schedule, individual, or Slack channel), how long to wait for acknowledgement before moving to the next level, and any routing conditions like working hours or incident priority.

On-call schedule: a rotation that defines which engineer is responsible for responding to alerts during a given time window. Escalation paths reference on-call schedules as their primary notification targets.

Alert routing: the configuration layer that connects an inbound alert from a monitoring tool (such as Datadog or Prometheus) to the correct escalation path. Alert routing evaluates attributes like service name or alert priority to decide which path to trigger.

Service Catalog: incident.io's internal registry of services, features, and teams. When populated with team ownership data, it allows alert routing to automatically page the correct team's escalation path without manual lookup during an incident.

Working hours: named time-window sets (for example, "UK hours: Mon–Fri 09:00–17:00 GMT") that you define once and reference inside escalation path branches. They let a single escalation path route and wait differently depending on whether an alert fires inside or outside business hours.