Observability is sold as a reliability investment. Look closer at what it actually is: an admission that your system can reach states you don't understand, so you are instrumenting it to find out after the fact. That is worth doing. It is not the same as being reliable, and confusing the two is how teams spend heavily and stay fragile.
A dashboard observes. It does not constrain. It tells you the system entered a bad state faster than you would otherwise have known — genuinely useful, and it changes nothing about whether the bad state was reachable. The same is true of the rest of the remediation toolkit. Rollbacks don't fix a poorly designed architecture; they return you to the previous version of the same design flaw. Alerts don't prevent failures; they shorten the gap between failure and human reaction, and we call that gap "reliability."
This is the difference between detecting and preventing, and it is not a matter of degree. Detection accepts that the failure happens and optimizes the response. Prevention makes the failure structurally impossible and has nothing to respond to. More observability improves the first and does nothing for the second — and a system that depends on fast human response is a system that fails the moment the response is slow, asleep, or looking the other way.
None of this is an argument against monitoring; you should see your system clearly. It is an argument against mistaking visibility for safety. The question observability can never answer is the only one that matters: not "will we notice when it breaks," but "can it break at all." If the honest answer is yes, the dashboard is not your defense. It is the record of how you found out.