Reliability is a product decision.
The experience does not stop when the feature ships. Someone still owns what happens when the dependency slows down, the data arrives late, or the happy path ends.
For a long time, technology organizations treated reliability as the work that followed product development. Builders created the change; an operations team absorbed the uncertainty. That separation looks tidy on an organization chart and feels very different at 2 a.m.
The better question is not, “Who supports this?” It is, “What did we decide about failure while we were designing it?” Monitoring, rollback, capacity, recovery, and clear ownership are choices about the user experience. They belong beside scope and architecture, not in a readiness checklist opened the week before launch.
A system reveals its product decisions most clearly when the expected path is no longer available.
This does not mean eliminating failure. It means making failure understandable. A useful alert carries context. A runbook reflects the current system. A service owner knows which tradeoff was made and why. The person responding should not have to reconstruct the design from telemetry fragments while the clock is running.
Reliability becomes less theatrical when it is part of ordinary work: one more acceptance criterion, one more design conversation, one more reason to test the uncomfortable path before a customer does.