Error Budgets for Integrations You Didn't Build

The SRE playbook is one of the best things to happen to operations, and it was written for a world we rarely work in. Google’s SRE practice assumes you own the service. You control the code, the deploys, the infrastructure, the rollback. Error budgets, SLOs, on-call: all of it rests on the idea that reliability is mostly in your hands.

Integrations aren’t like that. An integration sits between systems, and you own almost none of them. The partner API, the legacy host, the message broker, the third-party identity provider: each is a failure mode you can’t fix, only absorb. So when we run managed operations for integrations we didn’t necessarily build, we take the SRE toolkit and bend it to a harder situation: reliability you’re accountable for but only partly control.

Here’s how the core ideas translate.

Stop targeting 100%. Especially here.

The single most useful idea in the SRE book is that 100% reliability is the wrong target. Past a point, each increment of reliability costs an order of magnitude more than the last, and your users can’t even perceive it. Someone on a flaky phone can’t tell 99.99% from 99.999%. Chasing the last fraction just freezes feature work and burns money.

That’s true for a service you fully own. For an integration it’s a fantasy. Your effective reliability is bounded by the systems you depend on. If a partner API is up 99.9% of the time, your integration cannot beat 99.9% for anything that touches it, no matter how perfect your code is. Targeting 100% for a system that hangs off three dependencies you don’t run isn’t ambition. It’s a promise you have no mechanism to keep.

So the first conversation we have with a client is about picking a target that’s honest. Not the highest number that sounds impressive. The highest number the dependency chain can actually support, minus the margin you need to survive the days it misbehaves.

Do the error-budget math out loud

An error budget is just one minus your SLO, the amount of failure you’ve explicitly decided is acceptable. Putting real numbers on it changes the whole conversation, because the numbers are smaller than people expect.

At 99.9% (“three nines”) you get about 43 minutes of downtime a month. That’s it. One bad deploy, one partner outage, one certificate that expired over a weekend, and a chunk of the month’s budget is gone.

At 99.99% (“four nines”) you’re down to roughly 4 minutes a month. Four minutes. There is no room in four minutes for a human to wake up, read a page, and log in. Every failure at that tier has to be handled by automation, because people are too slow. Each extra nine cuts the allowed downtime by 10x and roughly 10x’s the cost of achieving it.

We make clients sit with these numbers before anyone signs an SLA, because the gap between “we want four nines” and “four nines means every incident is resolved before a human can react” is where unrealistic contracts are born. And here’s the distinction that matters legally: an SLO is your internal target; an SLA is a promise with consequences attached. The litmus test from the SRE book is simple: ask what happens if you miss it. If the answer is “a penalty,” it’s an SLA. Never write an SLA number your dependencies can’t back.

The budget is a decision-making tool, not a scoreboard

The part teams miss is that an error budget is meant to drive decisions, not just measure the past. Google’s example error-budget policy makes this concrete: when a service burns through its budget over a rolling four-week window, the policy halts all changes and releases except P0 fixes and security patches until the service is back inside its SLO. Spend the budget, lose the right to ship risky changes. It also mandates a postmortem for any single incident that eats more than 20% of the budget.

For integrations we adapt this to point at the dependency that’s actually failing. If a partner API’s instability is draining the budget, the response isn’t to freeze our releases. It’s to escalate to the partner, add a circuit breaker, cache more aggressively, or renegotiate the SLA to reflect reality. The budget tells you where the reliability is leaking. In a system you don’t fully own, that diagnostic is worth more than the number itself.

Alerts that respect the human

Operations lives or dies on alerting, and integrations generate more noise than most systems because there are more moving parts to complain. PagerDuty’s principle is the one we enforce: an alert is something that requires a human to do something. Anything that wakes a person at 3 AM must be immediately actionable. Everything else is a notification, and notifications must never interrupt sleep.

This is harder for integrations because a single upstream hiccup can light up five of your dashboards at once. Every API that depends on that upstream fails together. Without care, one partner outage pages your on-call five times for one root cause. So we tune toward a one-alert-per-incident target and tier ruthlessly: act-now-24/7, handle-in-business-hours, and eventual. An engineer woken for a problem they can’t act on learns to ignore the pager, and an ignored pager is worse than no pager.

Runbooks are where the 20 years live

Everything above is structure. The thing that actually shortens an outage is a runbook: the documented steps for a known failure mode. Restart this connector. Fail over to that region. Replay the outbox from this offset. Under pressure, at 3 AM, a responder shouldn’t be reasoning from first principles; they should be executing a procedure someone wrote calmly in daylight.

For integrations, the runbook is where hard-won judgment gets encoded. “When the partner returns HTTP 200 with an empty body, it means their backend is degraded. Don’t retry, switch to the cached response and open a ticket with them.” That line is 20 years of pattern recognition compressed into an instruction a tired on-call engineer can follow. It’s also the difference between managed operations that adds value and a monitoring dashboard that just tells you things are broken.

Build and run, on purpose

The reason we run what we build, and run things others built, is that the failure modes you designed for and the failure modes you operate through are the same failure modes. The team that wrote the retry logic knows exactly which upstream lies about its health, and that knowledge belongs in the runbook, not in one person’s head.

The SRE toolkit assumes ownership. Integration operations assumes the opposite: accountability without full control. Pick a target the dependency chain can support. Do the downtime math before you promise anything. Let the error budget point at the leak. Keep alerts actionable. And write the runbooks while the sun is up. That’s how you run a system you didn’t fully build without lying about what “reliable” means.