Tolerance in Duration

A tolerance in duration answers a single question: how long can this service be disrupted before the harm it causes becomes intolerable? The answer is a limit on the length of interruption, not a promise about how quickly engineers will work or how hard a team will try. Length matters because harm accumulates while a service is unavailable. A customer who cannot access funds, a merchant who cannot take payment, and a counterparty waiting for settlement all experience the same passing time differently, and the tolerance must reflect the service being considered rather than a generic sense that shorter is better.

Duration alone never tells the whole story, and this guide treats it as one dimension of a fuller tolerance. A brief stop at a moment of intense need can cause more harm than a longer stop at a quiet moment, and a service that returns inaccurately has not truly ended its disruption. Duration therefore has to be read alongside breadth and data, and alongside the rhythm of user need. The sections below examine what duration captures, where it misleads, and how it is judged in practice.

Duration captures the experience of waiting. For an online current account service, the illustration used here, a customer who cannot view a balance or move money is not experiencing a technical fault in the abstract. The customer is experiencing delay in a task that may be urgent, such as paying a bill before a deadline or checking whether a payment has arrived. As the interruption lengthens, the number of delayed tasks grows, workarounds become harder to sustain, and trust in the service erodes in a way that a later apology does not fully repair.

The harm of an interruption depends on what users need the service for at that moment. An account service that stops during a period when many customers check balances and make payments carries a heavier impact than the same stop during a quiet period, even though the length is identical. Settlement timing adds a further layer. A stop that straddles a settlement window can delay obligations to other firms, while a stop that falls outside that window may be absorbed more easily. The tolerance must therefore be understood in context, not as an isolated length that applies equally at every moment.

A duration limit can hide harm that arrives quickly or that persists after return. A service that returns with incorrect balances, duplicated payments, or missing transactions has ended its outage in a technical sense while continuing to harm users in a practical sense. Judged only by duration, that service appears to have recovered inside its limit. Judged by data and by customer outcome, it has not. Duration must therefore never be read as the sole test of whether a tolerance was met.

During an incident, a duration tolerance gives decision makers a reference point for escalation and communication. As the interruption lengthens toward the limit, the firm faces a choice: intensify recovery, activate workarounds, warn users more plainly, or prepare for the consequences of crossing the limit. Without a limit, those choices drift, because there is no agreed point at which the incident changes character from a technical problem to a harm event. With a limit, the conversation becomes concrete, even if the limit itself is later judged to have been set too generously.

A reader can test a duration tolerance by asking when users need the service most, what happens to queued work while the service is down, and what state the service is in when it returns. Further questions concern communication: at what point do users receive a plain account of the problem, and does that account arrive before frustration turns into harm? A tolerance that answers those questions in its supporting material is more than a length. It is a judgement about the service in time. A firm that reviews duration alongside breadth and data, rather than in isolation, is more likely to recognise when a service has truly recovered in harm terms.