4 April 2026 · Field notes
How to read a nine-minute error burst
A morning can be fine except for nine minutes. Those nine minutes still generate a letter, a status page, and a meeting. If you then chart the whole day as a single error rate, the burst becomes a faint bump and everyone argues about a bump.
We start by finding the first minute the chosen status codes leave their baseline, and the first minute they return. That pair of clocks is the frame. Everything else — deploys, restarts, certificate jobs, client campaigns — is a vertical rule that either sits inside the frame or does not. A restart after the burst is a fact. It is not a cause.
Timeouts are kept in a different ink from application 500s. A hung upstream and a thrown exception are different weather. If your gateway logs them as the same status, we will say the ink cannot split and the sitting will be more cautious.
The useful question in the room is rarely “was it bad.” It is “which upstream went quiet, which routes inherited that quiet, and which clients retried.” Retries inflate counts. If the log has a request id, we can collapse them. If it does not, the briefing will warn that the burst looks taller than the number of people who waited.
Bring an hour before and an hour after. Quiet is evidence. Without it, a burst has no ground to stand on, and the next meeting will stretch nine minutes into a morning because nobody can point at a return to baseline.