Introduction
Software reliability refers to the probability that a computer program runs without failure in a specified environment for a specified period. In other words, it is the ability of a system to perform its intended functions, under known conditions and over a predefined period.
Measuring this reliability is no theoretical exercise. The metrics that quantify it guide quality decisions, reveal weak points before they become costly, and make it possible to know, with figures to back it up, whether a product is ready to be put into users' hands. This stake has grown with the spread of cloud-native architectures and microservices, where an isolated failure can cascade across dozens of interdependent services, making rigorous measurement more essential than ever.
Why these metrics matter
The direct cost of poor quality
The stakes are first of all financial. According to a report regularly cited by the Consortium for Information and Software Quality (CISQ), poor software quality cost US companies more than $2 trillion in 2020, between production failures, emergency fixes and lost productivity. These costs rarely sit where you'd expect: a bug caught in production costs, according to studies repeated on the topic, dozens of times more to fix than a defect caught at design time.
Reputational risk and customer trust
On top of this direct loss comes a reputational risk that's hard to price but just as real: a visible outage, a service unavailable at the wrong moment, or a string of repeated incidents durably erode user trust and expose the brand to sometimes irreversible damage. Conversely, tracking reliability metrics delivers concrete, measurable benefits: you increase return on investment, identify bugs earlier in the cycle, reduce rework costs and optimize workflows. Measuring reliability thus becomes a quality lever as much as an economic argument in front of business leadership.
Time-based metrics: MTTF, MTTR and MTBF
Three long-standing metrics, drawn from reliability engineering, focus on time rather than on the volume of failures. As of 2026, they remain the foundation most reliability dashboards are built on, including for cloud-native and distributed systems.
MTTF: anticipating breakdowns
MTTF, mean time to failure, measures the average time elapsed between two failures under normal operating conditions. It applies in particular to non-repairable components, a disk you replace rather than repair, for instance, and helps teams anticipate breakdowns without accounting for the time needed for the repair itself.
MTTR: measuring repair effectiveness
MTTR, mean time to repair, conversely quantifies the average time needed to diagnose and fix a failure once it has occurred. It directly reflects the effectiveness of a team's fixing processes: quality of observability, clarity of runbooks, automation of fix deployment. A degrading MTTR is often the early signal of operational debt building up.
MTBF: the composite indicator
MTBF, mean time between failure, combines the two previous metrics to calculate the average interval between failures, repair included, and thus predict the next breakdown after service is restored. It's often the indicator presented to steering committees, since it summarizes in a single figure the actual operational availability experienced by users, where MTTF and MTTR each describe only half of the picture.
Frequency and availability metrics: ROCOF, POFOD and AVAIL
ROCOF: the frequency of failures
ROCOF, rate of occurrence of failure, represents the number of failures occurring over a given interval, per hour, per day or per million requests depending on the scale of the system. Unlike MTTF, it measures frequency rather than the duration between two events, which makes it particularly relevant for systems with very high request volumes, such as public APIs or payment platforms.
POFOD: the risk at the moment of demand
POFOD, probability of failure on demand, assesses the probability that a failure occurs precisely at the moment of a request. It suits systems used sporadically or in critical settings particularly well, an alarm-triggering system, a failover mechanism, where the number of calls is low but every failure has immediate, significant consequences.
AVAIL: operational availability
Finally, availability, or AVAIL, measures the percentage of time the system remains operational over a reference period. It's a decisive criterion for critical infrastructures such as telecommunications, banking or healthcare, often expressed in "number of nines", 99.9%, 99.95%, 99.99%,with each additional nine representing a substantially higher engineering effort and cost.
Instrumenting reliability: observability and chaos engineering
Observability and data collection
These six metrics don't compute themselves in the abstract: they require systematic instrumentation of production systems, structured logs, distributed traces and metrics exposed by every service, aggregated in an observability platform. Without this continuous collection, MTTR and MTBF remain rough estimates rather than indicators teams can act on daily.
Validating reliability through chaos engineering
Beyond passive measurement, practices such as chaos engineering let you actively test a system's reliability by injecting controlled failures, network outages, artificial latency, abruptly killing an instance, to verify that resilience mechanisms behave as expected and that the MTTR measured under real conditions matches the one obtained in simulation. It's one of the most reliable ways to trust your own metrics before a real incident puts them to the test.
From metrics to goals: SLIs, SLOs and error budgets
Measuring isn't enough: you also need to set goals. Site Reliability Engineering practice formalizes this move from raw metric to business objective by introducing service level indicators (SLIs), built from metrics such as AVAIL or ROCOF, and the associated service level objectives (SLOs).
The tolerated gap between the objective and reality is the error budget: as long as it isn't spent, the team can take risks and accelerate delivery; once exhausted, priority shifts to stabilization. Concretely, a 99.9% availability SLO over a month leaves a budget of about 43 minutes of cumulative downtime: beyond that, new feature deployments are frozen until the margin is restored. This connection turns metrics once confined to operations teams into a common language shared with product teams and business leadership, who can then consciously trade off delivery speed against reliability instead of having that trade-off imposed after the fact.
Deciding and progressing through measurement
Taken together, these six metrics cover the essential aspects of reliability: time between failures, repair time, failure frequency and availability. They offer an overall view that lets teams settle one concrete question: is the product reliable enough to ship, and at what level of residual risk?
Beyond this one-off decision, adopting these metrics feeds a dynamic of continuous improvement and strengthens the organization's quality culture. Building reliable software means measuring consistently, instrumenting every service from the design stage, and acting on the lessons learned rather than archiving them in a dashboard nobody looks at. At Adservio, we support teams in setting up these indicators, from instrumentation to defining SLOs, to steer quality and deliver robust products.
STAY POSTED
Get our next analyses and field notes straight to your inbox.
