Operations | Monitoring | ITSM | DevOps | Cloud

Monitoring tools track what’s happening across your systems and send a Slack message or email when something looks off. But they don’t call anyone and they don’t escalate the incident. If that Slack message goes unseen at 3 AM on a Saturday, the incident just sits there until someone opens their dashboard. Incident alerting fills this gap. When an incident triggers, it contacts the right person directly through a phone call or their preferred channel.

Critical incidents have a direct impact on your business revenue and the trust your customers place in you. The longer a critical incident goes unnoticed, the higher the stakes. A reliable alert routing setup automatically catches these incidents the moment they trigger and gets them to the right person without delay. This guide walks you through how to build that reliable routing setup.

When a midnight incident triggers, the goal is not to wake your entire team. It’s to reach the one person who can act on it. Everyone else should sleep through it undisturbed. The difference between a team that handles midnight incidents well and one that doesn’t usually comes down to a few decisions made ahead of time. Which incidents actually need a midnight response? Who should get the call? And what should happen to everything else? This guide walks through those decisions.

Severity and priority are two labels that describe different things about an incident. Severity covers the blast radius: how much of your system or how many customers are affected. Priority covers the urgency: how quickly someone needs to act. Routing rules then use these labels to load the right escalation policy for each incident. This guide covers how to define your severity and priority levels and map them to escalation policies.

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.