A service can be reachable while its most important journey is broken. Customers can sign in and browse, but cannot submit a request. A single availability number may hide the distinction that matters most to them.
Reliability discussions become more useful when they start with the promise the product makes. Which tasks do people depend on, when do they need them, and what happens when they cannot complete them?
Define the journey before the target
Take an illustrative appointment product. Searching for a time, confirming a booking, and changing an existing booking have different consequences when unavailable. The business may choose to protect them differently.
A useful reliability discussion names those tasks and agrees how success is observed. Google's service-level objectives chapter distinguishes the indicators used to measure a service from the objectives set for those indicators. That distinction helps keep a measurement from becoming a target merely because it is easy to collect.
For our appointment example, the team might examine whether confirmation completes within an acceptable period and whether the booking is retrievable afterward. The exact target should come from the product's needs and operating capacity, not a number copied from a larger company.
Make tradeoffs understandable
Protecting every feature to the same degree can consume effort without reflecting customer priorities. Ask what degraded operation would still allow people to finish essential work.
Could a reporting view be temporarily unavailable while booking continues? Could a less important integration pause while requests are preserved for later processing? These are product choices with engineering implications.
Describe the customer-facing behaviour as part of the decision. Degradation should not silently turn into a false success message or unexplained missing work. Support should be able to tell users what is happening and which actions remain possible.
Use failures to choose the next investment
When an incident occurs, examine which promise was broken and how the team discovered it. Was the relevant state visible? Did a workaround exist? Did the response depend on one person's knowledge?
The next improvement might be architectural, but it could also be better status visibility, a clearer operating procedure, or a narrower release. Connect the work to the failure it is intended to address.
Avoid reporting reliability only as a technical team's score. Product and business leaders should understand what the measures represent and which customer experiences they omit. That shared understanding makes it easier to prioritise reliability alongside feature work.
A dependable product does not emerge from an isolated uptime target. It comes from agreeing which promises matter, designing the system and operating process around them, and using evidence to decide where the next improvement belongs.