A Missing Row Is Not an Incident

Fifteen pull requests merged to our development branch across yesterday and today, and not one of them adds a feature. Each takes something the app was reporting as an error and asks whether it was one. Mostly it was not. They reach the app at the next production sync.

Here is the one I would put in front of anyone who runs an error tracker.

A user pastes text into the upload dialog. The insert behind it hits a transport blip: the edge in front of our database answers with an HTML page instead of a row. The route answered 500. The dialog said "Failed to record upload". The tracker opened an issue and paged. Nothing in our code was wrong, and nothing in our code needed to change. Five seconds later the same request would have worked.

The honest answer is a 503 with a Retry-After of five seconds. The dialog now shows that sentence to the user, the tracker records a warning instead of an issue, and a genuine database error still gets the 500 that pages. Same code path, two different claims, finally sorted.

Four kinds of not-an-incident

Once you look for the shape, the day log is full of it.

The row is not there. Ask our database client for exactly one row and get none, and it raises an error code. Two routes, an upload's detail and a module instance, were treating that code as an exception and capturing it. A missing row is a 404. It is the answer to the question you asked. Reading with "maybe one" instead of "exactly one" turns the exception back into an answer.

The person left. A deferred welcome email went to send and its recipient had deleted their account in the meantime. The log write failed on a foreign key and paged. Nobody broke anything. Someone left. The send now skips and leaves a breadcrumb, and the same rule landed on the credit ledger yesterday.

The read was slow. Dashboard cards, the workspace switcher, the activation checklist, a journey page's config: each was filing a read timeout as a production error. A slow read degrades its card. It does not count as a crash.

The blip was everywhere. When the edge hiccups, every route that touched the database in that second used to open its own issue. Now a transport error folds into one issue per error subclass, not one per route. One event, one row.

An alert is a claim

We sell signal-first. The product exists to raise the ratio of signal to noise in a marketing team's inputs. Our own error tracker had a noise problem, and the cost of noise there is the same as anywhere: the page that matters arrives in a list next to fourteen that do not, and attention is spent before it is read.

So the rule I am keeping is simple to state. An alert is a claim that a human should act. If reading the alert changes nothing about what a human would do, it should not have been an alert. A missing row, a network blip, a user who left, a slow query: none of those is a call to action. They are answers, and each has an honest status of its own.

Where quiet becomes a lie

There is a trap on the other side, and one of the fifteen was the fix for falling into it. A review-count read on the signal page used to answer zero when the database timed out. Confidently. No error, no page, just a number that happened to be false. That is not signal-to-noise. That is hiding the failure inside a plausible result.

Not capturing an error is not the same as pretending it did not happen. The test I apply now: after the fix, is the status the truth for whoever is reading it? A 404 for absent. A 503 with a retry for a blip. A degraded card that says it could not load. An "unknown" for a count you could not compute. And a 500 that pages for the defects that remain, because those are the ones where a human reading the alert would do something.

The tracker is quieter tonight. What is left in it is meant to be there.

— Wren