Translating Uptime Targets into Cost of Downtime
Concept
"99.9% uptime" is meaningless to anyone outside engineering until it's translated into what the other 0.1% actually costs the business. That translation runs in two directions, and both matter. First, forward: an availability target implies a concrete error budget — the amount of allowed unreliability before a service breaches its commitment. Google's SRE practice defines this precisely: an error budget is 1 − SLO. A 99.9% SLO gives a 0.1% error budget; over a 4-week window with 1,000,000 requests, that's a budget of 1,000 failed requests (or roughly 43 minutes of full downtime, if the failure mode is total unavailability rather than partial). Second, backward: that budget, once spent, has a dollar cost — lost revenue during the outage, engineering time spent responding and recovering, any contractual SLA penalty credits owed to customers, and harder-to-quantify costs like customer churn and reputational damage. Industry cost-of-downtime studies (Ponemon, Gartner, cited by Atlassian) put enterprise downtime cost anywhere from roughly $5,600 to $9,000 per minute on average, with wide variance by industry and business size — the number that matters is never an industry average, it's the specific business's own lost-revenue-per-minute during its own peak traffic.
The error budget's real organizational value, per Google's SRE workbook, isn't just measurement — it's a policy mechanism that resolves the structural conflict between "ship faster" (product/dev) and "break less" (ops/SRE). As long as a service hasn't exhausted its error budget for the period, the team is free to ship new features and take on the reliability risk that comes with velocity. Once the budget is spent, non-critical releases pause until reliability work brings the service back under budget — this makes reliability investment a resource allocation decision with a visible trigger, rather than a permanently-open argument between teams with different incentives.
Tradeoffs
| Approach to reliability investment | What it optimizes for | What it costs |
|---|---|---|
| No stated SLA/SLO, ad hoc reliability effort | Simplicity — no budget-tracking overhead | No objective trigger for when to prioritize reliability work vs features; arguments resolve by whoever's loudest, not by data |
| SLA/SLO with error budget, budget not tied to release policy | Visibility — team can see when they're over budget | Visibility alone doesn't change behavior; teams that see they're over budget but face no consequence often keep shipping features anyway |
| SLA/SLO with error budget enforced as a release gate (Google's model) | Aligns incentives mechanically — velocity and reliability compete for the same explicit budget | Requires organizational buy-in to actually halt releases when the budget's spent, which is a harder sell than just tracking the number |
| Tighter SLA than the business case justifies (e.g. 99.99% for a feature with no real revenue sensitivity to short outages) | Marketing/competitive positioning | Each additional "9" costs disproportionately more engineering effort for redundancy — see MTBF, MTTR, and Reliability Math — money and focus spent here isn't available for other priorities |
The core tradeoff underneath all of these: reliability isn't free, and every additional 9 of availability has to be justified against what an hour (or a minute) of downtime actually costs this business, not against an abstract "more reliable is always better" instinct.
When to use / when not to
- Do this translation before setting or renegotiating any SLA — estimate lost-revenue-per-hour during peak usage (lost transactions × average transaction value, or lost active users × revenue-per-user-hour) so the target being proposed has a concrete cost basis, not a round number picked because it sounds good.
- Use the error-budget-as-release-gate model once a team is large enough that reliability and feature work are genuinely competing for the same engineering time — it gives both sides an objective, shared number to argue from instead of competing narratives.
- Don't chase a higher uptime number than the actual cost-of-downtime math supports — if an hour of downtime costs relatively little (a low-traffic internal tool, an off-peak batch pipeline), the engineering cost of chasing 99.99% is very likely a worse use of time than the same effort spent elsewhere.
- Don't skip this exercise just because the business side hasn't asked for it — an SLA chosen without a cost basis tends to get renegotiated under pressure during an actual incident, which is the worst time to discover it wasn't grounded in real numbers.
Common pitfall
Using an industry-average cost-of-downtime figure instead of computing the business's own number. Industry studies report huge ranges (from a few thousand dollars per hour for a small business to millions for a large enterprise) precisely because the real number depends entirely on the specific business's revenue model, traffic patterns, and peak-vs-off-peak timing — a marketplace that loses bookings during a Saturday-evening outage has a very different cost profile than the same outage at 3am on a Tuesday. An SLA and its associated reliability investment justified by an unrelated industry average is not actually grounded in anything.
Engineering Lens
The move that makes this land in a planning or incident-postmortem conversation is walking the error budget's consumption for a specific outage in the same breath as its dollar cost — "this incident used 22% of this quarter's error budget, and at our peak-hour revenue rate that's roughly $X in lost transactions" — because it turns "we had an outage" into a resource-allocation fact the business side can act on directly, the same currency as a feature-prioritization tradeoff. Teams that only report uptime percentages, without ever translating them into cost, tend to lose the argument for reliability investment to teams that report feature revenue in dollars.