practice · operations

Daily triage

Fifteen minutes. Same time every weekday. Three streams: bug · brief input · noise. Each ticket and signal routed cleanly within 15 minutes — or surfaced for the trio's bi-weekly review. The discipline that keeps the support pipeline producing chain-level signals, not noise.

TL;DR

Daily triage is 15 minutes, same time every weekday, led by the CS Lead with the on-call PO in attendance. The session sorts the prior day's signals — incoming tickets, support escalations, and dashboard anomalies — into three streams: bug · brief input · noise. Each ticket is routed in under three minutes. Ambiguity is named, not resolved in-session; it goes to the trio.

What it is

Daily triage is the operational practice that protects the support-to-bug pipeline from clogging. It is described in After We Build · Bugs and Their Roots as the moment a ticket either becomes a tracked bug, becomes brief input for next cycle, or is filed as noise that doesn't move the chain.

Distinguish from

Standup — engineering team rhythm; triage is cross-role. Incident response — something has fired; triage is waiting for nothing, sorting yesterday's. Sprint planning — backlog negotiation; triage is signal routing. See Confusable with at the foot.

Why it matters

Without daily triage:

• The engineering backlog floods with tickets. Every CS escalation routes as a bug; the bug board becomes a queue of unsorted complaints.
• Patterns hide in single-tickets. Three tickets of the same shape arrive in 10 days but nobody connects them.
• Brief inputs die at L2. A ticket that is really a next cycle signal gets fixed as a one-off and forgotten.
• The signal reading writes itself blind. Without daily attention, the cycle's first-48h watch and the prediction's check are downstream of an unsorted stream.

The corpus rule: a bug is a ticket whose root traces to a chain level. Tickets that don't trace are either brief input (next cycle's work) or noise (filed, not actioned). Daily triage is the practice that draws those lines.

How to do it

Step 1 — Same time, same day, every weekday

15 minutes. 10:00 or right after the team standup is the corpus default. Skip it on weekends; do not skip it on a Monday. A skipped Monday means Tuesday's triage is sorting two days of signal — too much for 15 minutes.

Step 2 — Two attendees: CS Lead drives, on-call PO observes

The CS Lead drives — they're the one who has read yesterday's tickets and the helpdesk's overnight queue. The on-call PO observes — they don't sort; they listen for brief input candidates and pattern signals.

A daily triage with only the CS Lead is a routing exercise. A daily triage with both is the start of the support pipeline producing chain-level signals.

Step 3 — Three streams, sorted in under three minutes per ticket

For each ticket or signal from yesterday's queue:

Ticket #4218 — "Grader queue spinning on Monday morning"
  Volume:   1 ticket
  Cohort:   single grader, slow VPN
  Pattern:  none — similar tickets resolved >30 days ago
  Routing:  NOISE (single, known cause, no L2 escalation)
  Action:   reply with VPN troubleshooting; close.

Ticket #4221 — "Hebrew names rendering with garbage characters"
  Volume:   3 tickets in 48 hours
  Cohort:   all from new flagship campus rollout
  Pattern:  recurring — same root.
  Routing:  BUG → L2 escalation
  Action:   open INC-NNN for L2; link the three tickets.

Ticket #4225 — "Can the grader queue show subject when there are
              multiple courses?"
  Volume:   1 ticket
  Cohort:   senior grader, suggestion
  Pattern:  none yet
  Routing:  BRIEF INPUT → captured for next cycle's discovery
  Action:   note in next cycle's research pile; reply to grader
            acknowledging the suggestion.

If a ticket takes longer than three minutes to route, it doesn't get routed in this session. It goes to the unclear bucket for the trio to read at the bi-weekly sync. The corpus's discipline: triage is fast; depth lives elsewhere.

Step 4 — The three rules of routing

Bug:

• The ticket traces to a specific chain level (most often L4 Execution or L5 Operation).
• It is reproducible or has been reported by ≥2 named persons.
• A fix would be a story.

Brief input:

• The ticket suggests a change in what the team is building, not a defect in what was built.
• Often phrased as a suggestion, a workaround request, or a new use case.
• Goes into the next cycle's discovery pile, not the bug backlog.

Noise:

• Configuration, account, or known-issue lookup that L1 resolves.
• Single occurrence with no pattern.
• Filed (not deleted); searchable later if a pattern emerges.

Step 5 — Name the unclear and let the trio decide

Tickets that don't sort cleanly in three minutes are not forced into one of the three buckets. They go to the unclear list, read at the next bi-weekly sync or surfaced to the trio's quick async thread.

The discipline against the wrong-routing failure mode is honesty about ambiguity, not heroic in-session decisions.

Step 6 — Weekly summary

Every Friday, the CS Lead writes a five-line summary of the week's triage:

Triage summary, week of 2026-05-18:
  Tickets routed: 47
  Bugs (escalated to L2): 4
  Brief inputs (next cycle pile): 6
  Noise (filed, no action): 35
  Unclear (trio): 2 — [link to thread]

Theme this week: Hebrew name rendering for legacy unicode set
(3 bugs trace to same root; INC-072 covers the structural fix).

This summary feeds the weekly client update and the next bi-weekly sync.

Evidence

Across our cycles, daily triage that produced clean signals shared three properties.

1. The session held to 15 minutes. Triage that ran over 25 minutes was usually solving in-session instead of routing — the depth belongs at the bi-weekly sync.
2. At least one ticket per week went to brief input. Cycles where every ticket routed as bug or noise had bug backlogs that grew 2× faster than cycles where the team honestly named next cycle signals.
3. The CS Lead and PO both attended. Cycles with CS-only triage produced fewer brief-input routings; the PO's presence is what spots the next cycle signal.

Anti-patterns

Pattern	What it looks like	Where to fix
Triage skipped on quiet days	"Nothing new came in"	Hold it anyway. 5 minutes of nothing routed is data.
Every ticket routed as bug	Engineering backlog floods	Clinic — A runbook that doesn't run — patterns hide in noise; brief inputs hide in bugs
Triage as group decision	8 people in the room	Two attendees. More is sprint planning.
Triage runs 30+ minutes	The team is solving, not routing	Move ambiguity to the unclear bucket; depth belongs at the sync.
Triage held the day after a quiet weekend	Monday triage skipped	Hold every weekday; Monday catches up on the weekend's signal.
No weekly summary	Triage happens; the trio doesn't read it	Five lines, every Friday. Feeds the weekly client update.

Confusable with

This	Not this	Difference
Daily triage	Standup	Standup = engineering. Triage = cross-role routing of yesterday's signals.
Daily triage	Incident response	Triage = waiting for nothing; sorting. Incident response = something fires.
Bug	Brief input	Bug = defect, traces to a chain level. Brief input = new requirement, goes to discovery.
Noise	Junk	Noise is filed, not deleted. Searchable when a pattern emerges.

Further reading

• Canon — After We Build · Bugs and Their Roots · Did We Serve · The Ongoing Relationship — Support-to-bug pipeline
• Practice — Helpdesk reading · Weekly client update
• Checklist — Daily triage · 15 minutes
• Skill path — CS Lead foundations · Step 4
• Reference — Area · Support-to-bug pipeline