Setting up an escalation policy for the first time can feel like standing at a crossroads with no clear sign pointing the way. You could escalate based on severity, by team, or by who’s available and all of them are valid. Knowing which one fits your situation is the hard part. Think of this guide as your compass for that decision. The five approaches below are the different directions you can take and a combination of two or three usually covers most situations well.
Table of contents
Approach 1: Severity and priority-based
Severity and priority-based policies are probably the most common approach to escalation. Each incident gets a severity or priority label and that decides which escalation policy it follows.
Severity describes the impact of an incident. Priority describes how urgently it needs to be addressed. Teams usually define three tiers for each: SEV-1, SEV-2 and SEV-3 for severity and P1, P2 and P3 for priority. Some teams go up to P4 or P5 as their incident volume grows and their classification gets more granular.
A SEV-1 incident like a payment service going down, triggers a phone call to the on-call responder. With no acknowledgment after five minutes, it moves to a senior engineer. A P1 incident like an enterprise customer losing access to a core feature, gets an urgent response because the business impact is high. A SEV-2 or P2 incident like a non-critical service running slower than usual, might trigger a phone call only during business hours.
One thing worth sorting out before you set up these policies is a shared definition of what each severity and priority label actually means for your team. Without that agreement, the same incident gets classified differently by different people and the policy behaves inconsistently.
A useful question to ask when deciding what counts as critical: which incident would wake you up at 3am? That’s your SEV-1 or P1. Everything else falls below it.
Learn more about escalation policies for critical incidents and low-priority incidents
Severity and priority-based routing is a solid first choice for almost any team. If you’re just getting started and aren’t sure where to begin, this is probably the right first step. It also scales naturally as your incident volume grows and your definitions get sharper.
In Spike, Alert Rules automatically route incidents to the right escalation policy based on their severity or priority.
Approach 2: Role-based
Role-based escalation policies route incidents based on people’s roles in the team rather than what the incident is.
The most common version is a three-tier structure:
L1: The on-call responder. Gets first contact and owns the initial response.L2: The team lead or senior engineer. Steps in if L1 doesn’t acknowledge or needs support.L3: The engineering manager or incident commander. Enters the chain for high-impact incidents that need broader coordination.
Learn more about L1, L2, L3 escalation policy →
Each role has a clear responsibility in the chain. L1 triages the incident and attempts a fix. If the incident isn’t resolved within a set time, it moves to L2. L3 comes in when the situation needs someone with the authority to make bigger decisions or pull in more people.
Role-based policies work well when your team has distinct functions and clear ownership across different parts of the system. If you want incidents to follow a structured path rather than land with whoever happens to be free, this approach is worth setting up alongside your severity-based policies.
Approach 3: Channel-based
Channel-based policies focus on how an incident reaches someone rather than who receives it. A phone call at midnight communicates urgency in a way a Slack message simply doesn’t. That difference is intentional. The channel itself is part of the message.
Critical incidents usually warrant a phone call. A phone call demands attention. Lower-severity incidents where team awareness matters more than immediate action are a good fit for a Slack or Microsoft Teams notification. A failed email notification to a single user or a non-critical service running slower than usual probably doesn’t need to wake anyone up. A channel post is enough.
Channel-based thinking also works well as a starting point for teams that haven’t yet defined severity levels. Rather than asking “is this SEV-1 or SEV-2?”, the question becomes simpler: does this need a phone call or a Slack message? The channel carries the urgency signal. It’s an easier decision to make and still gets the right incidents to the right people quickly.
Approach 4: Team-based
Team-based policies route incidents to the team that owns the affected system.
For example,
- A security breach goes to the security team
- A database failure goes to the SRE team
Each team only sees the incidents that belong to them.
This approach suits larger organisations where distinct teams own distinct parts of the system. It keeps teams focused on their area and stops the wrong people from being pulled into incidents outside their work.
For smaller teams where everyone owns most things, this level of separation probably isn’t necessary yet. A five-person engineering team rarely needs separate escalation paths for separate sub-teams. As the team grows and system ownership becomes more specialised, team-based policies start to make more sense. It’s more of a direction to grow into than something to set up from day one.
Approach 5: Time-based
Time-based policies are less a standalone approach and more a layer you add on top of any of the others. The incident itself doesn’t change. What changes is your team’s availability and how quickly a response is needed.
The same P1 incident might call for an immediate phone call at 11pm but only a Slack message at 10am when the team is likely already online.
A time layer is worth adding once your core policies are in place. Many teams add it a few weeks in when they notice the same policy doesn’t quite fit every time window. It doesn’t require rebuilding anything from scratch. It just makes every existing policy more precise.
In Spike, you can set up time-based conditions in Alert Rules to load different escalation policies depending on the time of day. A separate escalation policy for business hours and another for off-hours. Alert Rules then decide which one gets applied when an incident triggers.
There’s no single escalation setup that fits every team. What matters is that the policies you put in place reflect how your team actually works. Most teams find that a combination of two or three approaches covers most situations well. Something as simple as a severity-based policy with channel and time conditions layered in goes a long way.
Go ahead and try something. You’ll refine it as you learn.
FAQs
Can the same person appear in multiple escalation policies?
Yes, and that’s quite common. For instance, your engineering manager might sit in the last step of several escalation policies. The main thing is to make sure that the person knows they’re in the chain and understands how and when they’ll be contacted.
How many escalation policies does a team typically need?
There’s no fixed number. Many teams run well with two or three. The number usually grows naturally as you learn your incident patterns. It’s rarely worth trying to predict the right number upfront.
Can incidents from the same integration follow different escalation policies?
Yes. In Spike, alert rules let you route incidents based on their content. Two incidents from the same integration can follow entirely different policies if the payload carries different severity labels or keywords.