"We had an incident" is the polite version of a more precise sentence: "our architecture permitted a state we had not designed for." Downtime almost never arrives from outside. The traffic spike, the dependency failure, the bad deploy — those are weather. Whether the system survives the weather was decided long before the storm, in the boundaries that were or were not drawn.
The claim worth arguing with: uptime is not an operational achievement. It is an architectural property. If staying up depends on engineers being awake, you do not have reliability — you have luck with good reflexes, and reflexes do not scale. Every manual intervention that "saved" a system is evidence of a failure mode the architecture left open and quietly outsourced to a human being with a pager.
This is why buying more monitoring rarely moves the number. Monitoring tells you the system entered a bad state faster. It does not make the bad state unreachable. Dashboards observe; they do not constrain. Reliability comes from what the system is structurally not allowed to do — isolated failure domains, controlled degradation, invariants that hold under load — not from how quickly someone notices it doing the wrong thing.
The proof is in the systems that have already lived it. A credit bureau through which roughly 92% of an entire industry's credit decisions pass has run for more than fifteen years without an interruption. That is not luck sustained across fifteen years — luck does not have that kind of stamina. It is the visible output of an architecture in which the failure modes that take ordinary systems down were made unreachable rather than merely survivable. When 92% of a sector cannot transact without you, "we'll bring it back up quickly" was never an acceptable answer. The only acceptable answer is a system that does not enter the state at all.
Five-nines is a measurement. The architecture that makes it inevitable is a decision — and it is made long before the first nine.