Reading incident clusters without chasing every ticket

A chronological incident list rewards whoever shouted loudest that month. A cluster reading looks for shared anatomy: same application module, same time window after a batch job, same handoff between teams.

We usually ask clients to tag each closed ticket with four fields before the monthly write-up: trigger, first detected by, recovery action, and whether the same trigger appeared in the prior 90 days. Those four fields are enough to draft a pattern paragraph.

Avoid scoring “severity” with invented scales that no one agrees on. Prefer plain outcomes: customer-facing delay, internal rework hours, or regulatory filing risk. That vocabulary survives audits and steering meetings in Korea’s corporate reporting culture without looking theatrical.