SLA Stacking: Why Your Composite Availability Is Lower Than Any Vendor Promised

Every vendor in your stack can keep its promise and your product can still break yours. I have sat in more than one post-incident review where the room went quiet because nobody had done anything wrong. The CDN was inside its SLA. The identity provider was inside its SLA. The model provider was inside its SLA. And the customer-facing product had just burned through its entire quarterly error budget in a month. Nobody lied. The math simply was never done.

That math has a name, composite availability, and it is one of the oldest ideas in reliability engineering. What has changed is how many dependencies a modern product leans on, and how agentic AI workflows have quietly turned a handful of hard dependencies into dozens of calls per user request. If you own delivery, release commitments, or the availability number that goes into a customer contract, this is now your problem as much as the SRE team's.

The multiplication nobody puts on the roadmap

When your service needs two components to both be up, its availability is the product of theirs, not the minimum. Two components at 99.9 percent do not give you 99.9 percent. They give you 99.8 percent, and that missing tenth of a point is roughly nine extra hours of downtime a year.

It compounds fast. Five hard dependencies at 99.9 percent each put you at about 99.5 percent, which is roughly 44 hours of expected downtime a year. Ten of them put you at about 99.0 percent, or 87 hours. Your own code has not failed once in that model. Those hours are inherited.

Google's SRE team made this point formally in The Calculus of Service Availability: a service cannot be more available than the intersection of its critical dependencies, so each critical dependency needs to be meaningfully more available than the service that depends on it, roughly one extra nine. Most programs I see do the opposite. They sign a 99.9 percent customer SLA on top of a stack of 99.9 percent vendor SLAs and assume it nets out.

If your contract promises the same number of nines as your weakest critical vendor, you have already promised something you cannot deliver.

Agentic workflows turn availability into a per-run success rate

Traditional services hit a dependency once or twice per request. An agent hits them repeatedly. A fairly ordinary agent run plans with a model call, retrieves from a vector store, calls three or four tool APIs, asks the model to reason over the results, verifies, and writes back. Twelve calls is a modest run. Thirty is not unusual for a multi-step task.

Each of those calls is a chance to fail, and the run fails if any non-recoverable step fails. At 99 percent success per call, a 12-call run succeeds about 88.6 percent of the time without retries. At 1,000 runs a day, that is around 114 failed runs every single day, from a stack where every component looks green on its own status page.

This is why I keep telling teams that agent reliability is a delivery metric, not a model-quality metric. The model can be excellent and the run still fails because a tool endpoint timed out on step nine. I made a similar argument about dependency density as a program risk signal: the count and coupling of dependencies predicts trouble better than any single node's quality. Runtime availability behaves the same way.

Retries help, but only with independent failures

The instinctive fix is retries, and they do help. If failures are independent and you retry each call once, a 1 percent per-call failure becomes 0.01 percent, and the 12-call run climbs back to about 99.9 percent.

The catch is the word independent. A retry rescues you from a dropped packet or a transient 503. It does nothing when the provider is having a regional incident, because your second attempt fails for exactly the same reason as the first. Correlated failures are the ones that consume error budgets, and they are the ones retries cannot touch. Worse, aggressive retries against a struggling dependency add load at the worst possible moment. Retries are a jitter fix, not an outage strategy.

Topology is the lever, not vendor negotiation

When teams discover the stacking problem, their first move is usually to push vendors for a better SLA. That rarely works, and even when it does, an SLA is a refund policy, not an engineering property. The service credits you receive after an outage are a rounding error next to the revenue and trust you lose.

The real lever is topology. The same two components produce wildly different availability depending on how you wire them.

• Serial is the default and the most expensive. Every hard dependency multiplies in.
• Redundant paths flip the math. Two independent 99.9 percent paths, where either can serve, give you better than 99.999 percent, provided the failures really are independent. Two regions on the same provider control plane are not independent.
• Degraded fallback is often the most practical answer for AI features. When the primary model is unavailable, route to a smaller model, a cached answer, or a deterministic rule. Quality dips for a while; the outage never reaches the customer.

The design question I push teams to answer for every dependency is simple: if this is down for an hour, what does the user see? If the answer is "an error page," that dependency is hard and it multiplies. If the answer is "a slightly worse result," it is soft, and it mostly drops out of the math.

What delivery leaders should actually do

This is not only architecture work. Most of it is planning, contracting, and release governance, which is squarely delivery territory.

1. Build an availability budget before you sign the SLA

Treat the customer-facing number as a budget and allocate it down the dependency chain, the same way you would allocate a latency budget or a cost budget. List every hard dependency on the critical user journey, write down its contractual and observed availability, and multiply. If the product is below what sales wants to promise, you have three choices: change the topology, change the promise, or accept the risk explicitly and in writing. All three are legitimate. Discovering the gap during an incident is not.

2. Map hard versus soft dependencies on the critical path

Your dependency map probably already shows what calls what. Add one attribute: hard or soft. Then review every new integration through that lens at design time. An architecture decision record that says "we accept the LLM provider as a hard dependency for checkout" forces a conversation that "we added an AI summary to checkout" never will.

3. Measure observed availability, not contractual availability

Vendor status pages report their view of their service, usually aggregated and usually generous. Measure the success rate of your calls to each dependency from your side of the wire. That is the number that multiplies into your user experience, and it is frequently a full nine worse than the contract implies.

4. Tie it to your error budget policy

If your team already runs on SLOs, extend the error budget to cover inherited failures explicitly. Budget burned by a vendor is still budget burned. When a single dependency consumes a meaningful share of the budget two quarters in a row, that is the signal to invest in a fallback path, not to file another support ticket.

5. Count agent calls like you count dependencies

For agentic features, track calls per run and per-run success rate as first-class delivery metrics, alongside the cost metrics most teams already watch. A prompt or planning change that adds four tool calls to the average run is an availability change, and it deserves to be reviewed like one.

The honest number

The AWS Well-Architected reliability pillar guidance on availability walks through the same serial and redundant calculations, and the arithmetic is not the hard part. The hard part is organizational: the person promising the number to the customer is rarely the person who knows how many hard dependencies sit under it.

Close that gap. Put the multiplication in the planning deck, next to the scope and the date. The goal is not a stack with no dependencies. The goal is a promise that survives contact with the stack you actually have.

References

• Ben Treynor, Mike Dahlin, Vivek Rau, Betsy Beyer. The Calculus of Service Availability. ACM Queue. queue.acm.org
• Amazon Web Services. Availability, Reliability Pillar, AWS Well-Architected Framework. docs.aws.amazon.com
• Google. Site Reliability Engineering: Embracing Risk. sre.google