Triage

011 min

Triage at a glance

• What it is: A recurring sort-and-decide habit, not a one-time scoring framework like RICE.
• Origin: French trier, "to sort"; formalized on the battlefield by surgeon Dominique-Jean Larrey around 1792.
• Produces: A labeled, time-boxed queue, such as GitLab's severity::1 (1 week) through severity::4 (90 days).
• Fails when: Severity labels inflate until "urgent" is applied to everything and means nothing.

021 min

What breaks without Triage

Without triage, a growing backlog gets worked in whatever order it happens to arrive, or whoever complains loudest gets attention first, and neither of those has anything to do with actual impact. A critical outage reported quietly by one enterprise customer can sit behind a dozen cosmetic bug reports filed earlier the same morning, simply because nobody made an explicit, repeated decision about which items matter more than which others, and arrival order quietly became the de facto priority system instead.

The failure this produces is specific and recognizable: a team that reacts in arrival order or by volume of complaints is optimizing for whoever files the most tickets or shouts the loudest in Slack, not for whoever is actually blocked worst. A support queue with no triage step eventually trains its users to escalate everything immediately, since a calm, well-written ticket gets the same treatment as an urgent one. Triage exists to interrupt that default with a deliberate, recurring sort, so the queue a team actually works reflects a real judgment about urgency and impact, rather than the accident of who showed up first or shouted hardest.

032 min

How Triage works

Triage's mechanics are the same whether the sorted items are patients or support tickets: assign each incoming item a severity or priority tier, then let that tier set how fast it has to be addressed. GitLab's public handbook runs exactly this structure on software bugs, publishing the resolution window each severity tier commits to:

GitLab's own description of the purpose: "Severity labels help us determine urgency and clearly communicate the impact of a bug or maintenance issue on users." Kubernetes runs a similar mechanic through automation rather than a fixed table: "New issues are automatically assigned a needs-triage label indicating that these issues are currently awaiting triage. After triaging an issue, the issue owning SIG will use the bot command /triage accepted," and issues left untouched for 90 days are automatically flagged stale by the project's own bot rather than by a person remembering to check.

The worked example is the decision itself, repeated at scale: a new bug report arrives, someone decides which tier it belongs in based on how many users it affects and how badly, and that tier decision, not the order the report arrived in, determines when it gets worked. A report that silently blocks a small number of paying customers from checking out at all is a severity::1 regardless of when it was filed; a cosmetic spacing issue on a settings page stays a severity::4 even if it was reported first thing that morning.

Applying the mechanics does not produce a good decision automatically. A tier assigned by whoever is loudest in the room, rather than by actual measured impact, produces exactly the same bad outcome triage was meant to prevent, just with an official-looking label attached to it, which is why the tier assignment itself, not the existence of a label scheme, is the part that has to be done carefully.

041 min

Where Triage came from

"Triage" comes from the French trier, to sort, and its first systematic use is usually traced to Dominique-Jean Larrey, Napoleon's chief surgeon, who developed a battlefield system around 1792 for deciding which wounded soldiers to treat first. Larrey's own stated principle broke sharply with the custom of his time: "We would always start with the most dangerously wounded without regard to rank or distinction," and "those less severely wounded must wait until the gravely hurt have been operated and addressed." Treating by severity of wound rather than by rank or order of arrival was, for the period, a genuinely unusual innovation, and it is the same principle every modern severity-labeled bug queue still runs on.

051 min

Real-world examples

GitLab's public engineering handbook runs issue triage as a named, public process rather than an informal habit: every bug or maintenance issue gets a severity label, and that label carries a committed resolution window, from one week for severity::1 down to 90 days for severity::4. The process is published, not just practiced internally, which makes it one of the few software triage systems a reader can actually go and verify by visiting the handbook page itself, rather than taking a company's word for how it says it works.

Shopify's own bug-bounty team published a concrete, dated before-and-after on triage speed in its 2018 year-in-review: "In 2017, our average time to triage was four days. In 2018, we shaved that down to 10 hours, despite largely receiving the same volume of reports." That is a real, falsifiable, company-reported metric with both a before number and an after number attached to specific years, not a vague claim of improvement, and it shows triage itself, the act of sorting and deciding, getting measurably faster as a process independent of how many reports arrived that year. Both examples share the same underlying move: a team decided to measure and publish its own triage performance, rather than treating the sorting step as invisible overhead nobody tracks.

062 min

How to run Triage this week

Running triage this week needs no new tool, only a recurring slot and a small, consistently-applied label set. Start by defining three to four severity tiers in plain language tied to user impact, the way GitLab's severity::1 through severity::4 tiers are each tied to a specific resolution window rather than to a vague sense of importance. Second, set a fixed, recurring time, a standing weekly or twice-weekly slot, when every new item gets assigned a tier; triage done only when someone happens to remember quietly turns back into first-come-first-served, which is the exact failure mode triage exists to prevent.

Third, treat the resolution window itself as a forcing function: write the tier directly onto the item as a label in whatever tracker the team already uses, a spreadsheet column, a GitHub or Jira label, or GitLab's own severity labels, so the tier is visible to anyone who opens the item later, not just to whoever assigned it in the moment. Fourth, review the oldest items in each tier before adding new ones to the same tier, since an item that has sat in severity::2 for 25 days is closer to breaching its own committed window than a report filed five minutes ago, and a triage pass that only looks at new arrivals will miss that every time.

By the end of one cycle, the artifact triage produces is a labeled, time-boxed queue in which every open item has an assigned tier and an implied deadline, rather than an undifferentiated pile sorted only by arrival time. No specialized software is required to start; a shared spreadsheet with a severity column and a "days since filed" formula does the same job a dedicated ticketing system's labels do, just with more manual upkeep and no automated stale-item flagging.

071 min

Triage done badly

The clearest named failure of triage is severity inflation: once "urgent" or "P0" gets applied to something that is not actually urgent, the label stops carrying information, and every subsequent item has to be marked even more urgent to stand out, until the whole scheme collapses into noise. Microsoft engineer Raymond Chen named this directly in a 2008 post on priority creep: "eventually everything is top priority," describing what he calls "priority inflation," the repeated introduction of new "top priority" items until the category means nothing.

The tell is specific and checkable: look at the distribution of severity or priority labels across the open queue. If a large share of items sit in the highest tier, the tiers are not doing their job, because a scheme meant to separate the genuinely urgent few from everything else has instead been applied to most of the queue. The fix is not a stricter label, it is re-auditing what "urgent" actually means and moving items that do not meet that bar back down, even when that is an uncomfortable conversation with whoever filed them.

081 min

Triage vs. nearby concepts

Triage is often confused with a one-time prioritization framework like RICE or MoSCoW scoring, but they answer different questions at different frequencies. A scoring framework produces a ranked list from a fixed set of candidates, usually for a planning exercise done once per quarter or roadmap cycle. Triage is a recurring, ongoing sort applied to whatever has newly arrived since the last pass, run daily or weekly rather than quarterly, and its output is a tier and a deadline, not a rank-ordered list.

It is also distinct from deciding the single next action on one item already in hand, which is a one-item decision about what to do next, not a sorting pass across many competing items. And it differs from opportunity cost reasoning, which asks what a team gives up by choosing one thing; triage asks which of many already-arrived things should be looked at first, a sorting question triage answers before any opportunity-cost trade-off between two specific options even comes up.

092 min

A second case

Kubernetes' public contributor process is a second, differently-shaped triage system worth contrasting with GitLab's. Where GitLab runs triage as an internal company process with human-assigned severity tiers, Kubernetes runs it through bot-enforced automation across a large, distributed, volunteer contributor base: "New issues are automatically assigned a needs-triage label indicating that these issues are currently awaiting triage. After triaging an issue, the issue owning SIG will use the bot command /triage accepted," and issues that go 90 days without activity are automatically marked stale by the project's own triage bot rather than by any single person remembering to review them.

The variable that differs between the two cases is who enforces the tier and how. GitLab's severity labels are applied by a person who judges user impact directly, and the resolution window is a commitment a human team is accountable for meeting. Kubernetes' labels are applied and aged out largely by automation, because no single team owns every issue in a project with contributors spread across dozens of organizations and companies, and a bot-enforced stale timer substitutes for a team that would otherwise need to manually re-review a queue nobody individually owns outright. What the contrast teaches is that triage's core mechanic, sort by tier, let the tier set urgency, survives being run by either a person or a bot; what changes is only who is accountable when a tier assignment turns out to have been wrong.

101 min

Where the evidence is contested

The sharpest practitioner critique of formal triage systems is not that sorting is a bad idea, it is that a severity scheme can decay into what amounts to theater: labels get applied, resolution windows get published, and the queue still does not actually reflect real impact, because the labeling step itself became the goal rather than a means to get the right things worked first. Raymond Chen's "priority inflation" post is one named, dated account of exactly this decay, where the category meant to flag the few truly urgent items instead gets applied to most of the queue until the label carries no information at all.

A more recent practitioner source, the observability company Last9, describes the same pattern under its own name, in the specific context of incident response rather than bug tracking: "Overusing 'P1' and 'P2' can lead to alert fatigue, burnout, and ultimately slower response times for truly critical incidents." Neither source argues the fix is more process; both point toward the same practical stance, that a severity or priority label is only as useful as the discipline behind re-auditing it, and a team that adds more tiers or stricter resolution windows without first fixing why the existing ones inflated is very likely to watch the new scheme inflate exactly the same way the old one did, just with better-looking documentation around it.

111 min

How Triage changed since

Triage began as battlefield practice with no written framework attached beyond Larrey's own stated principle of treating by wound severity rather than by military rank. Civilian medicine formalized the idea over the following two centuries into the structured, multi-tier triage scales used in emergency rooms today, where an arriving patient is assigned a numbered acuity level that determines how quickly they are seen, the direct institutional descendant of Larrey's original battlefield sort, now run by trained triage nurses rather than a single battlefield surgeon.

Software and product teams borrowed the word, not the medical apparatus, sometime in the past few decades as bug trackers and support queues grew too large to work in arrival order by hand. What carried over is the core move, sort by severity, let severity set urgency, stripped of anything specific to triage's medical origin; a GitLab severity::1 label and an emergency room's highest acuity level share a lineage back to the same battlefield principle, even though nothing about resolving a software checkout bug resembles treating a gunshot wound.

122 min

Frequently asked questions

Who should run triage? Whoever owns the queue being sorted: an engineering lead for a bug tracker, a support manager for a ticket queue, an incident commander for live incidents. The role matters less than that one person or rotation is accountable for the recurring pass happening at all.

What do you need in place before starting triage? A small, fixed set of severity or priority tiers defined in plain, impact-based language, and a place to record which tier each item got, whether that is a label in an existing tracker or a column in a shared spreadsheet.

What is an example of triage? GitLab's public handbook assigns every bug a severity label tied to a resolution window, from one week for the most severe down to 90 days for the least. Kubernetes runs a similar sort through bot-applied labels across its open-source contributor base.

What do you do if triage doesn't work? Check the distribution of labels across the open queue first. If most items sit in the top tier, the tiers have inflated and stopped carrying information, and the fix is auditing what counts as urgent, not adding a stricter label on top of an already-broken one.

How is triage different from a prioritization framework like RICE? A prioritization framework scores a fixed set of candidates once, usually for a planning cycle. Triage is a recurring sort applied to whatever newly arrived since the last pass, producing a severity tier and an implied deadline rather than a ranked list.

?5 questions

Questions people ask

§7 sources

Sources