Every dashboard answers the same kind of question: how is the system performing? Latency, throughput, error rate, uptime. All of it measures what the system is doing. None of it measures what the system must never do — and that is the failure that actually ends companies.
The states that matter most are the ones a system should be structurally incapable of entering: the double-spend, the order that ships without payment, the decision that crosses a hard regulatory line, the balance that goes somewhere it can never go. These do not appear as a spike on a graph, because they are not a performance problem. They are a correctness problem, and correctness has no column on the dashboard. By the time a forbidden state is visible, it is not a warning — it is an incident report, a clawback, a regulator's letter.
Which is why "we'll monitor for it" is a quiet admission of defeat. Monitoring means the system can enter the bad state and you are hoping to notice in time. Reliability worth the name comes from the opposite posture: enumerating the states the system must never reach, and making them unreachable by construction — not discouraged, not alerted on. Unreachable.
This inverts how most teams specify systems. They write down what the system should do, at length, and leave what it must never do to intuition and good intentions. But the should-do list is infinite and forgiving; the must-never list is short, knowable, and unforgiving. A team that cannot recite its forbidden states has not defined reliability. It has defined features and called the gaps "edge cases" — and the edge is exactly where the company gets cut.