Skip to main content
Incident triage is the rapid initial assessment of a newly reported problem: how bad is it, how urgent is it, and how wide does it reach? The output of triage is a severity assignment and a decision about who responds and how fast. Done well, it takes minutes and ensures a proportional response—major failures get immediate mobilization, minor ones don’t wake anyone up.

​
Where does the term come from?

Triage is borrowed from emergency medicine, where clinicians sort incoming patients by urgency rather than arrival order—treating the critical case first even if someone else has been waiting longer. The insight transfers directly to operations: response capacity is finite, and the order in which you spend it matters more than raw speed. A team that handles alerts strictly first-in-first-out will inevitably burn its best responders on trivia while something serious waits in the queue.

​
What questions does triage answer?

Effective triage runs through a short, consistent set of questions:
  • Impact: what is actually broken? Is functionality degraded or fully down? Is data at risk? Is revenue affected? Distinguish “the dashboard looks weird” from “customers cannot pay us.”
  • Urgency: is it getting worse? A slow memory leak and a cascading failure both matter, but on very different clocks. Urgency determines whether the response starts now or at 9 a.m.
  • Scope: who is affected? All customers or one? A single region or every region? Internal tooling or customer-facing paths? Scope is the difference between a SEV3 and a SEV1 for the same symptom.
  • Certainty: what do we actually know? Is this confirmed by monitoring, or a single unverified report? Triage with low certainty should err toward investigating quickly rather than mobilizing everyone.
The questions deliberately avoid why is it broken—root cause is a response activity, not a triage one. Trying to diagnose during triage delays the mobilization the diagnosis needs.

​
How does severity assignment work?

Triage concludes by mapping the answers onto the organization’s severity scale—typically SEV1 (critical) through SEV4 or SEV5 (minor). The severity then drives everything mechanical: who gets paged, whether a dedicated incident channel opens, how often stakeholders get updates, and whether a retrospective is required. This is why severity definitions need to be written down and unambiguous; triage under pressure is exactly the wrong time to debate what “major impact” means. Rootly lets you define these levels—with descriptions and notification behavior—under severities, so the person triaging picks from a shared menu instead of inventing a judgment call. Two rules keep severity assignment healthy:
  • When unsure, round up. Downgrading an over-called SEV2 costs a few apologetic messages; upgrading an under-called one costs response time you never get back.
  • Severity is provisional. Re-triage as facts arrive. An incident that looked contained at declaration can and should be upgraded the moment scope grows.

​
Who does the triage?

In most organizations, the first responder triages—usually the on-call engineer who received the alert, since waiting for a designated triager adds latency exactly where it hurts most. Larger organizations sometimes add a dedicated first-line rotation that triages everything and escalates to service owners. Whoever does it needs two things: authority to assign a severity without asking permission, and written severity definitions so their 3 a.m. judgment matches the team’s daytime intent.

​
What does triage look like in practice?

An on-call engineer is paged at 22:40: elevated error rates on the file-upload service. In four minutes she establishes: uploads are failing for roughly 30% of requests (impact: partial degradation of one feature), the rate has been flat for 20 minutes (urgency: not cascading), it affects all regions but only the upload path (scope: broad but narrow), and it’s confirmed by two independent monitors (certainty: high). She assigns SEV2—significant customer impact, not a full outage—which pages the storage team’s on-call and opens an incident channel, but doesn’t trigger the executive-notification workflow a SEV1 would. Total time from page to proportional response: about five minutes, and nobody was over- or under-mobilized. Browse all definitions in the incident management glossary.