The Spectrum of Availability

What Availability Actually Means

Let's start with the question that almost never gets asked clearly: available to do what?

A web server could be "up" in the sense that the process is running, but returning 500 errors to every request. A database could be accepting connections but taking 30 seconds to respond to each query. A payment service could be processing transactions but silently dropping 5% of them. Are any of these systems "available"?

The honest answer is: it depends on how you define it. And this is not a philosophical point. Systems get shipped with no clear definition of availability, and then engineers argue for months about whether a 3-hour incident "counted" as an outage or just "degraded performance." That argument is unwinnable because the terms were never defined upfront.

A useful working definition is: a system is available to a user if, from that user's perspective, it responds correctly within an acceptable time. Every word in that sentence is load-bearing:

From the user's perspective — not from the load balancer's perspective, not from the health check endpoint's perspective. If users are getting errors, the system is unavailable, even if your infra dashboards show everything as green.

Responds correctly — returning a 200 with the wrong data is not "available." Returning a cached stale response that's three days old might also not be "available," depending on what the user needs.

Within an acceptable time — a request that takes 60 seconds is functionally unavailable for most interactive use cases. Slow is the new down.

The Real Numbers Behind the Percentages

When someone says "we need four nines of availability," they often have not stopped to think about what that means in practice. Here is the math, laid out plainly.

Look at the jump from 99.9% to 99.99%. You go from 43 minutes of allowed downtime per month to 4 minutes. That's a 10x reduction in the amount of time you're allowed to be broken. In practice, that means you cannot do a slow rolling deployment that takes 5 minutes. You cannot run a database migration that causes 8 minutes of degraded performance. A single on-call engineer who takes 6 minutes to respond to a page and fix an issue has blown through your entire monthly budget.

The engineering cost to go from 99.9% to 99.99% is not 10% more work. It is often a fundamentally different architecture — redundancy at every layer, automated failover, zero-downtime deployments, and significantly more operational overhead.

SLIs, SLOs, and SLAs — A Precise Vocabulary

These three terms get used interchangeably in most engineering conversations, and that causes real problems. They are not interchangeable. They describe three different things at three different levels of the system.

SLI — The Measurement

An SLI (Service Level Indicator) is a concrete measurement of something your system does. It is a number, produced by instrumentation. Examples:

• The percentage of HTTP requests that return a 2xx status code in the last 5 minutes
• The 99th percentile latency of requests to the checkout endpoint over a 1-minute window
• The number of successful writes to the database per second
• The percentage of batch jobs that complete within their expected time window

An SLI is not a target. It is just a measurement. You can have a very accurate SLI that looks terrible — the measurement is fine, the system is bad.

Choosing the right SLI is harder than it looks. The most common mistake is measuring something that is easy to instrument rather than something that reflects the user's experience. CPU utilization is easy to measure. Whether users are actually having a good experience is harder. Always prefer user-facing SLIs — error rate, latency, and throughput as experienced at the application layer — over infrastructure metrics like CPU, memory, or disk.

SLO — The Target

An SLO (Service Level Objective) is a target for an SLI over a measurement window. It is an internal engineering commitment, not a customer contract. Examples:

• "99.9% of requests should return 2xx within 300ms, measured over a rolling 30-day window"
• "The p99 latency of the search API should be below 500ms, measured over a 1-hour window"
• "At least 99.5% of scheduled batch jobs should complete within their expected window each day"

Notice the SLO has three components: a metric (the SLI), a threshold (the number), and a window (the time range). All three matter.

The window is where teams often make subtle mistakes. A 30-day rolling window is more forgiving than a calendar-month window during the first days of the month (you have buffer from the previous 29 days). A 5-minute window is unforgiving — a 10-second blip shows up as a 3% error rate. Think carefully about what window matches how users actually experience your system.

SLOs should be set slightly tighter than what you actually deliver, but not so tight that you're always in violation. A useful heuristic: set your SLO at a level where missing it is a real signal that something needs to change, not just background noise.

SLA — The Contract

An SLA (Service Level Agreement) is a contract between you and your customers. It has consequences when you miss it — usually financial, in the form of service credits. Examples: "If monthly uptime falls below 99.9%, customers receive a 10% credit on their bill."

The critical relationship between SLOs and SLAs: your SLA should always be weaker than your internal SLO. If you have an internal SLO of 99.9% availability and you sign an SLA promising 99.9%, you have no margin. Any week where you hit exactly your internal target, you are in SLA violation. You need the SLO to be harder — say 99.95% internally — so that even if you occasionally miss the internal target, you still stay above the external SLA commitment.

Error Budgets — The Most Useful Tool in Reliability Engineering

Here is a tension that exists in nearly every software organization: the engineering team wants to ship features fast. The reliability team wants to prevent incidents. These goals feel like they are in conflict, and so they become political. Engineers argue "this deployment is safe." Reliability engineers argue "we've had too many incidents lately." Nobody wins, and both sides feel frustrated.

The error budget is a tool that makes this conversation mathematical instead of political.

What an Error Budget Is

If your SLO is 99.9% availability over a 30-day window, that means you are allowed to be unavailable for 0.1% of that time. 0.1% of 30 days is 43.8 minutes. That 43.8 minutes is your error budget — the amount of unreliability you are allowed to "spend" in a month.

This budget can be spent in any way. A planned deployment that causes 5 minutes of degraded performance uses 5 minutes of the budget. An unexpected incident that causes 30 minutes of high error rates uses 30 minutes. A bad config push that takes 8 minutes to roll back uses 8 minutes. When the budget is gone, it's gone — you've used up your allowed unreliability for the month.

How to Use the Budget to Make Decisions

The power of error budgets is that they turn the reliability vs. velocity trade-off into an explicit, shared resource with clear rules:

When the budget is healthy — you have plenty of error budget left — go fast. Ship features. Run experiments. Deploy frequently. You have headroom and you should use it. Sitting on unused error budget is waste; it means you're being more reliable than you need to be, and that extra reliability has a cost (slower deployments, more conservative changes).

When the budget is low — you have consumed most of your error budget — slow down. Stop non-critical deployments. Focus the team on reliability work: fixing the flaky service, adding better circuit breakers, improving alerting. The budget being low is a signal, not a punishment.

When the budget is exhausted — you have spent all of it — stop. No new feature deployments until the window resets or you fix the underlying reliability problem. This is not a suggestion; it is the agreed-upon rule, established before any incident happened.

The Error Budget Policy

The error budget itself is just a number. The error budget policy is the written agreement that describes what happens at different budget levels. Without a policy, the budget is just a dashboard that no one acts on.

A good policy answers these questions:

• What triggers a deployment freeze? (e.g., budget below 10% remaining for the window)
• What work is paused vs. allowed to continue during a freeze? (New features vs. bug fixes vs. emergency patches)
• Who can override the policy and under what circumstances?
• What happens when budget consistently runs out month after month? (Revisit the SLO, invest in reliability work, reassign engineers)

This policy must be written and agreed upon by both the product team and the engineering team before a crisis. If you try to establish the policy during an incident, you'll get arguments instead of alignment.

Measuring the Budget Correctly

There is a subtle but important question: what counts toward burning the error budget? There are a few schools of thought.

Everything counts — any time your SLI falls below the SLO threshold, you burn budget. This includes planned maintenance, voluntary degradation, external dependency failures, and your own bugs. The argument for this: users don't care why they experienced downtime. From their perspective, a planned maintenance window and an unexpected incident are both "the service was unavailable."

Some things are excluded — some teams exclude budget burn from causes outside their control (e.g., a cloud provider's regional outage). The argument: your team should not be penalized for failures they couldn't have prevented. The counter-argument: this creates perverse incentives to blame external causes.

There is no universally right answer, but the more important principle is: whatever you decide, be consistent. Changing the rules mid-month when things look bad destroys the whole point of having an objective measure.

Availability Is a Property of a Call Chain

Here is one of the most important and most overlooked facts about availability in distributed systems: the availability of a system that calls other systems is always lower than the availability of any single component.

If your service calls three other services to handle a request, and all three need to succeed for the request to succeed, then your service can only be as available as all three combined.

Let's make this concrete. Suppose you have a request that passes through five services, each with 99.9% availability:

// Five services, each at 99.9% availability
A = 0.999 × 0.999 × 0.999 × 0.999 × 0.999
A = 0.999⁵
A ≈ 0.995   // 99.5% — you've lost half a nine

// Ten services, each at 99.9%
A = 0.999¹⁰ ≈ 0.990   // 99.0%

// Twenty services, each at 99.9%
A = 0.999²⁰ ≈ 0.980   // 98.0% — nearly two full nines gone

This is the hidden cost of microservices that rarely gets discussed in architecture reviews. Every service you add to the call path of a critical request reduces your end-to-end availability — even if each individual service is rock solid.

This is why a monolith can actually have higher availability than a microservices architecture, even if individual microservices are more reliable than the equivalent components in the monolith. The monolith has fewer network hops, fewer failure boundaries, fewer points of failure in a single request's critical path.

How to Improve Call Chain Availability

There are four main strategies, and they're not mutually exclusive:

1. Shorten the chain. Every service you remove from the critical path improves end-to-end availability. Ask whether every dependency is truly necessary for the primary path, or whether it can be made asynchronous.

2. Make dependencies asynchronous. If Service B doesn't need to respond before you can reply to the user, don't put it in the synchronous critical path. Write to a queue and process it later. Your availability is no longer coupled to B's availability for that request.

3. Use fallbacks and degraded modes. If Service C is unavailable, can you return a useful response without it — perhaps a cached result, a default value, or a simplified version? This is covered in depth in Chapter 14, but the key point here is: a service that can degrade gracefully when a dependency is down contributes much less to end-to-end unavailability.

4. Set higher SLOs for shared dependencies. If twenty services depend on Service X, and Service X is at 99.9%, it is putting a ceiling on the availability of all twenty of those services. Shared, high-fan-in dependencies need to be held to a higher standard than leaf services. They should have tighter SLOs, more redundancy, and more careful deployment practices.

Parallel Dependencies vs. Serial Dependencies

Not all call chains are serial. Sometimes you call multiple services in parallel and need at least one to succeed (or need all of them). The math is different in each case.

For parallel calls where all must succeed, the formula is the same as serial — multiply. It does not matter that the calls happen simultaneously; if any one fails, the request fails.

For parallel calls where only one needs to succeed (e.g., you have a primary and a fallback), the math is much more forgiving:

Two independent services at 99.9% in a primary/fallback configuration give you six nines. This is why redundancy is so powerful — and why the default response to "we need higher availability" is usually "add a redundant instance," not "make the single instance more reliable."

How to Measure Availability in Practice

You cannot manage what you cannot measure, and measuring availability correctly is harder than it looks.

Synthetic Monitoring vs. Real User Monitoring

Synthetic monitoring means you have external probes that send requests to your service at regular intervals and record success/failure. These probes look like users, but they are not users. They hit the same few endpoints, with the same simple request, from a small number of known locations. They are good for detecting complete outages quickly.

Real user monitoring (RUM) means measuring success and failure rates in your actual production traffic. This is more accurate — it reflects what real users actually experience — but it requires you to have production traffic, and errors in low-traffic time windows can be statistically noisy.

The right answer is usually both. Synthetic monitoring catches outages fast, before real users are affected at scale. Real user monitoring catches subtle degradation that probes miss — like a particular request pattern that only real users trigger, or a geographic region that's degraded but not completely down.

The Window Problem

Availability is always measured over a time window, and the choice of window changes what you can see.

A short window (minutes to hours) is sensitive to brief spikes — a 2-minute incident looks catastrophic in a 5-minute window. This is good for alerting, where you want to be paged quickly. It is bad for SLO measurement, where a 2-minute incident out of 30 days should not look like you're violating your SLO.

A long rolling window (28 or 30 days) smooths out brief incidents. This is appropriate for SLO measurement and error budget tracking. The rolling window is better than a calendar month because it does not reset to zero at midnight on the 1st — your error budget carries over continuously.

A very long window (quarters or years) is useful for understanding trends but too slow for operational decisions. If your availability has been degrading for six months and you only notice at the quarterly review, it is too late.

In practice, most teams maintain two views: a short-window view for alerting and incident response, and a rolling 30-day view for SLO tracking and error budget management.

The Most Common Mistakes

Having seen how availability should work in theory, here are the places where things go wrong in practice — repeatedly, predictably, at companies of all sizes.

Setting SLOs Too Tight

There is a temptation, especially when talking to customers or executives, to set ambitious SLOs. "We target five nines!" sounds impressive. But if you are a team of 8 engineers running a service that you deploy twice a week, five nines is simply not achievable without heroic operational work — and that heroism has a cost. Engineer burnout, slow development, and constant fire-fighting are all symptoms of an SLO that is set too high for the team's actual capacity.

The right SLO is one that represents genuinely good service for your users without requiring unsustainable operational effort. For most internal services, 99.9% is perfectly reasonable. For customer-facing services at significant scale, 99.95% is ambitious but achievable. For critical financial infrastructure, 99.99% requires dedicated reliability engineering investment. Five nines is appropriate for a handful of the most critical systems in the world.

Measuring the Wrong Thing

Your health check endpoint returns 200 OK. Your monitoring says availability is 100%. But users are getting errors on every checkout because the payment service integration is broken — and your health check doesn't test that path. This is measuring the wrong thing.

The health check measures whether the server is up. It does not measure whether users are having a good experience. Always validate that your SLI measurement actually correlates with user outcomes. A useful test: if your SLI says 99.9% but users are filing complaints about errors, your SLI is measuring the wrong thing.

No Error Budget Policy

Many teams define SLOs and even track error budgets, but never write a policy for what to do when the budget runs low. The budget becomes a number on a dashboard that everyone glances at and forgets. When you finally exhaust the budget, there is no agreed-upon response, so you get the same political argument that error budgets were supposed to prevent.

Write the policy before you need it. Make it short, specific, and pre-agreed. "If we burn more than 50% of our monthly error budget in a single week, we pause all non-critical deployments for the following week." That is actionable. "We should be more careful about availability" is not.

Treating Availability as a Single-Service Property

The most common mistake at the system design level: teams optimize their individual service to have high availability and consider the job done. But no user experiences a single service in isolation. They experience the full request path. If your service is at 99.99% but the database it depends on is at 99.9%, the users experience 99.9% availability. Your extra nines are invisible to them.

When reasoning about availability targets, always think about the full call path from the user's request to the response. Map every dependency, identify the weakest link, and either accept that the chain's availability is bounded by that weak link or invest in making that dependency more reliable.