Operations | Monitoring | ITSM | DevOps | Cloud

Every incident arrives with a payload, and that payload usually tells you far more than whether something broke. It points to which service is affected and how serious the issue looks. It also carries context about which customers are on the receiving end of that failure. The service name, severity, customer context — all of it can feed directly into routing decisions. This guide explores how to read those parts of the payload and use them to route incidents automatically.

When an incident triggers, the question is not just what broke but also how urgent it is and who on your team needs to respond. Alert Routing rules answer those questions automatically. You define the conditions once and the right response follows every time an incident triggers. Every Alert Routing rule does one or more of these three things: Three conditions drive all of it: incident payload, time of occurrence, and frequency.

Over time, on-call teams build up a quiet layer of knowledge about their systems. Someone learns that a specific error code always means phone calls are failing. Someone else figures out that a particular background job fires a warning every night and has never once needed attention. That knowledge shapes how your team responds to incidents every day. But when it only lives in people’s heads, your response depends entirely on the right person being available at the right time.

Different incidents need different levels of attention. Some need a phone call at 3 AM and others can wait until morning. Alert Routing rules are what let you act on that understanding without doing it manually every time. An effective routing setup does three things: Getting all three of these working is what makes a routing setup useful.

When a critical incident triggers, there’s no time to figure out who to call. That decision needs to be made well before the incident arrives. A dedicated escalation policy for critical incidents gives your team a clear path to follow the moment things go wrong, rather than leaving it to whoever happens to be around. This guide covers the key decisions involved in building that policy.

Low-priority incidents are easy to deprioritise in the moment. Each one feels small and manageable. But without a proper escalation policy, they pile up quietly and reviewing them later often tells a different story. A simple escalation policy is usually all it takes to keep them from slipping through entirely.

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.

When a critical incident triggers, there’s no time to figure out who to call. That decision needs to be made well before the incident arrives. A dedicated escalation policy for critical incidents gives your team a clear path to follow the moment things go wrong, rather than leaving it to whoever happens to be around. This guide covers the key decisions involved in building that policy.

L1, L2, L3 is one of the most common ways to structure an escalation policy. The idea is simple: an incident triggers and lands with a first responder. If it needs more attention, it moves up the chain to someone with more expertise. This guide explains how each tier works, when this structure makes sense, and what to keep in mind when setting one up.

Teams put a lot of thought into how critical incidents are handled. Low-priority incidents usually don’t get the same attention. And without a proper escalation policy, they just land in a shared channel, waiting for someone to acknowledge. Setting up a clear policy for them is worth doing. Not because they need the same urgency as a critical incident, but because having a defined path for every incident makes the whole system more reliable.