Most Incidents Come From A Case Somebody Decided Could Not Happen

The impossible branch is not rare in production. It is where production spends a surprising amount of its time.

Read enough incident write ups and a pattern emerges that is almost monotonous. The condition that caused the outage was considered during design and dismissed. It could not occur, because an upstream system guaranteed otherwise, or because the values were always within a known range, or because two things never arrived at once. Each dismissal was reasonable given what was known. Each was true for a long time. Then something changed at the far end of a chain nobody had drawn in full, the impossible condition occurred, and the code that met it had no idea what to do because it had been written on the assumption that it would never be asked.

The lesson is not that every assumption must be defended against. That way lies logic so hedged it cannot be read, and it does not even work, since exhaustive defence is impossible and the effort spreads attention thin. The lesson is narrower and more practical: an assumption you rely on is worth making explicit, and worth checking cheaply where it enters. If a value must be within a range, say so at the boundary and reject what is not. This costs almost nothing and converts a mysterious downstream failure into an immediate, located, self describing one.

The second half is cultural rather than technical. When somebody says a case cannot happen, the useful follow up is not disagreement but curiosity: what guarantees it, who owns that guarantee, and would we find out if it changed? Very often the guarantee is real but owned by a different team, undocumented, and entirely capable of being relaxed by people who have no idea you depend on it. Writing that dependency down, even as a single sentence beside the code, converts an invisible coupling into a visible one, and visible couplings are the kind that get noticed before they break.