## TL;DR
During a major incident, triage is not about solving tickets. It is about sorting the flood: tag everything related to the incident, point those customers at the status update, and keep the unrelated queue moving. Declare one incident tag, pin one status message, and route all matching tickets to it. Agents who try to troubleshoot individually during an incident just create 200 duplicate investigations.

## The query

```text
how to triage tickets during a major incident
```

## Use this when

- An outage or major bug spikes ticket volume
- Writing incident response runbooks for support
- Agents are drowning and troubleshooting the same issue separately
- You need a repeatable incident triage process

## Not for

- Engineering incident response (mitigation, rollback)
- Root-cause analysis
- Postmortem writing
- Minor bugs with normal volume

## Steps

### 1. Declare the incident tag within five minutes

The moment volume spikes on one symptom, create the tag (e.g. "incident-2026-10-05-login") and announce it in the team channel. Every agent tags matching tickets instead of working them. No tag, no coordination.

Expected output: one tag, announced to the whole team.

### 2. Pin one status message and link it everywhere

Write the customer-facing status update once: what is broken, who is affected, what to do (usually: wait), and when the next update lands. Link it in every macro and auto-reply for tagged tickets. One message, updated in place.

Expected output: a single living status message.

### 3. Deflect the incident tickets, work the rest

Tagged tickets get the status link and a "we will update you" reply, then wait. Do not troubleshoot them individually. Meanwhile, keep a skeleton crew on the unrelated queue so normal customers are not abandoned.

Expected output: incident tickets parked, normal queue still moving.

### 4. Protect the on-call from ticket noise

Route engineering questions through one liaison. Fifty agents pinging the on-call with "customer X asks..." slows the fix. The liaison batches questions and relays the ETA back to support.

Expected output: one liaison, batched questions, posted ETAs.

### 5. Close the loop when it resolves

Update the status message, then bulk-update tagged tickets: resolved, with the summary. Track which tagged tickets need individual follow-up (data loss, billing impact) and work those after.

Expected output: all incident tickets closed or queued for follow-up.

## Template: the incident triage checklist

```text
INCIDENT TRIAGE - first 15 minutes
[ ] Tag created and announced: _______________
[ ] Status message written and linked: _______________
[ ] Deflect macro live for tagged tickets
[ ] Skeleton crew assigned to unrelated queue
[ ] Liaison named for engineering questions
[ ] Next status update scheduled: _______________

DO NOT: troubleshoot incident tickets individually, promise ETAs you do not have, ping the on-call directly.
```

## Variant phrasings

### outage ticket triage

Steps 1 through 3. Tag, status, deflect.

### too many tickets during an incident

Steps 3 and 4. Stop individual troubleshooting, protect the on-call.

### support runbook for major incidents

Full sequence. Print it and keep it where the team can find it at 3am.

## Why it works

Incident tickets are 95 percent identical. Individual troubleshooting multiplies work without multiplying information: 200 agents investigating the same outage learn nothing the first one did not. Tagging plus a single status message converts 200 investigations into one communication task, and the skeleton crew keeps the business running for everyone else.

## Edge cases

- Two incidents at once: two tags, two status messages, and split the team explicitly.
- The incident is partial (some regions fine): say exactly who is affected. Vague status messages create more tickets.
- VIP customers during incidents: they get the status link plus a named contact, not a different truth.
- The fix creates follow-up work (data backfill): tag a second wave for post-incident cleanup.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3NbbuFrPP7bi5qy-B8d7Ng
