SLOs and Error Budgets for API Integration Services

Four terms get thrown around like they're interchangeable, and they're not. SLIs, SLOs, error budgets, and SLAs form a chain, and each link depends on the one before it. Get the order wrong and the whole thing collapses into vibes-based reliability management, which is exactly the phrase that should scare any engineering leader reading this.

Start with the SLI, the service level indicator. It's a ratio: good events divided by total events, measured as close to the user as possible. Database CPU is not an SLI. Nobody's customer has ever complained about your CPU usage. HTTP success rate is an SLI. Latency at the 99th percentile is an SLI. If a metric doesn't describe something a user actually experiences, it doesn't belong in this conversation.

The SLO, the service level objective, is the target you set on that ratio. Say 99.9%. That number isn't decorative, it's the thing that generates everything downstream of it. Subtract the SLO from 100% and the remainder is your error budget: the amount of failure you're allowed before you've broken your promise. At 99.9% over a 30-day window, that budget is 43.2 minutes. Not "about 43 minutes." Exactly 43.2, because the math is just 0.1% of 43,200 minutes in a month.

The compliance window matters more than people give it credit for. It decides how old failures get weighted, when the budget resets, and how fast a bad week can burn through the whole reserve. A 7-day window and a 30-day window on the same SLO tell very different stories about how much trouble you're in right now.

Then there's the SLA, the service level agreement, which is a different animal entirely. SLOs are internal. Nobody outside engineering and product signs off on an SLO, and there's no penalty for missing one beyond an uncomfortable meeting. SLAs are external contracts, usually with financial consequences attached. The SLO should always be stricter than the SLA, because you want to know you're in trouble before your customer's legal team does.

Of the four, the error budget is the one doing the real work. As reliability writer Alex Ewerlöf has put it, the error budget is what turns "are we reliable enough?" from a philosophical debate into a number a product manager and an engineer can both look at and agree on. It's spendable. It's trackable. It ends arguments.

What this section hasn't touched yet: what happens to this whole tidy hierarchy when the thing generating your failures isn't your code at all, but somebody else's API. That's where the model starts to wobble.

Why third-party APIs break the standard SLO model

Here's the constraint nobody can engineer their way around: your service's ceiling is your dependency's floor. If the payment processor you're calling runs at 99.9% availability, your integration layer is fundamentally constrained by that ceiling no matter how good your code is. That's not a pessimistic take, it's a structural reality: a dependency's reliability sets the upper bound for anything built on top of it.

Most teams have a real error budget policy for internal work and then get blindsided anyway, because the incident retro keeps landing on the same line: "dependency X was degraded." That's not a coincidence, it's a pattern, and it points to a gap between how the policy was written and how failure actually shows up.

Third-party failure differs from internal failure in three specific ways, and each one removes a tool from the usual incident response kit:

• No fix to deploy. When your own service breaks, someone ships a patch. When the upstream breaks, the options are retries, fallbacks, and circuit breakers, full stop.
• No visibility into root cause. Their internal dashboards, their postmortems, their infrastructure choices: none of it is yours to see. You get a status page update if you're lucky.
• Their SLA runs on their calendar. Credits and penalties get processed on the vendor's timeline and their definition of an "incident," which rarely matches yours.

Then there's a failure mode that doesn't even show up as a failure at first glance. An upstream API can return a clean HTTP 200 with a payload that's stale, empty, or just wrong. Status-code monitoring says everything's fine. The user staring at an empty search results page disagrees. Teams that take this seriously start counting those responses as bad events, because a technically successful request that breaks the user's task is still a broken request.

This is also where the user-facing SLO and the component-level SLO need to split apart. Users experience the whole path, checkout, search, login, whatever it is, end to end. Engineering needs to know which specific link in that chain is burning the budget. Blend the two together and accountability disappears into a fog of "well, something's slow somewhere."

Once you accept that the failure mode itself looks different, the next question writes itself: how do you build SLIs that actually catch this stuff instead of quietly missing it?

Defining SLIs that reflect what third-party API failure actually looks like

The four golden signals, availability, latency, throughput, and error rate, still apply. The trick is where you point them. Measure at the boundary where your integration layer hands data off to the rest of your system, not at the vendor's own status page. Their status page reflects their version of the truth, self-reported and often generous. Your measurement point should reflect what your system actually received.

Availability, for an integration, means the percentage of requests that come back as a 2xx or an expected 4xx. A 5xx counts against the budget, as does any response that represents a genuine upstream failure. A client-side 4xx does not count against the budget, because that reflects an error on the calling side, not a failure of the upstream.

Latency needs more than one number, because a single average hides the parts that actually hurt:

• p50, for what a typical request feels like on a normal day.
• p99, for the tail latency that shows up as a visible stall to real users.
• p99.9, reserved for financial or transactional flows, where a slow tail has a direct dollar cost attached.

Then there's the trickiest one: semantic correctness. A response can be well-formed and still wrong, an empty result from a broken search index, a recommendation payload that's clearly outdated. Define what "good" looks like at the payload level, not just the protocol level, and count deviations against the budget. This is harder to instrument than a status code check, but skipping it means missing the failures your customers actually notice.

Keep it to two or three SLIs per integration. One for availability, one for latency, maybe one for correctness if the integration warrants it. Stack on more than that and every dashboard turns into wallpaper nobody reads during an actual incident.

Last piece, and it's the one that makes everything downstream possible: tag every bad event as internal or external at the moment it's recorded. Without that tag, every budget overrun looks like a shared mystery. With it, the data tells you exactly where to point the finger, which turns out to matter a lot in the next section.

Setting realistic SLO targets when the upstream variable is out of your control

A 99.9% SLO on a customer-facing integration buys 43.8 minutes of downtime a month. One bad upstream incident, the kind that runs an hour because a vendor's on-call engineer was asleep, and the whole month's budget is gone before lunch. So the target has to be grounded in what the dependency actually delivers, not what would look good in a slide deck.

The right way to set that number is boring and it works: run the integration for 30 to 60 days and just watch it. For services that have already been live a while, pull the last 90 days and set the initial SLO below the observed average performance. Not the best day, not the mean. A conservative baseline, because the target should survive a below-average day.

Different flows call for different tolerances, and pretending otherwise is how teams end up chasing five nines on a messaging-app notification integration nobody's revenue depends on:

Customer-facing integrations can usually live at 99.5% to start. Very few end users actually need four nines, and chasing that number on an API you don't control is an expensive way to fail anyway. Internal integrations, analytics pipelines, background enrichment jobs, can run 1 to 2% looser, because a 15-minute lag on an internal dashboard is an inconvenience, not an incident. Financial and transactional flows are the exception: tighten the tail-latency target at p99.9, but keep the availability number honest and grounded in what's actually been observed, not what sounds responsible in a compliance review.

There's also a negotiation buried in here that's easy to miss. A mobile app with on-device caching shrugs off an outage that would take down a synchronous web checkout flow instantly. The SLO has to satisfy the most demanding legitimate consumer of that integration, not whichever one is loudest in the planning meeting.

Set the actual target a notch below demonstrated performance. That gap is breathing room, space to deploy, to experiment, to absorb a weird Tuesday without triggering a budget crisis every other week. And for a brand-new integration with zero history, start conservative, 99.0 to 99.5%, and tighten only once real data backs it up. One hard rule worth keeping: if the target is stricter than what the upstream actually delivers in practice, there must be a mitigation architecture, caching, fallbacks, something, that can actually cover the gap.

Write all of it down. Standard SRE guidance is worth following here: record whether the number came from experiment or observation, log the approval date, and set a review date. For a third-party dependency, that review date matters more than almost anywhere else, because the vendor's reliability can shift without sending you so much as an email.

Allocating error budget across a dependency you don't control

Put a number on it. A service pulling 10 million requests a month at a 99.5% SLO has 50,000 allowed failures sitting in its budget. The real question isn't whether that number is big enough, it's how many of those 50,000 are going to get eaten by the vendor before there's anything left for the team's own mistakes.

That calls for splitting the budget into two buckets instead of pretending it's one pool:

• Upstream allocation: the slice reserved for the failures the vendor is expected to generate, based on their track record or their stated SLA.
• Internal allocation: what's left over for the team's own deploys, bugs, and misconfigurations.

Once the upstream's historical share of a normal month is known, deployment cadence and risk tolerance for internal changes should get sized to fit inside what's left, not the full budget as if the vendor doesn't exist. This is where the attribution tagging from earlier stops being a nice-to-have and becomes the thing that gives the whole policy teeth. Skip the tagging, and every overage looks like a shared, unownable mess that nobody can act on.

Multi-service flows need the same separation discussed earlier applied here too: user-facing SLOs track the whole journey, component SLOs isolate which piece is actually burning through the reserve.

Some of this deserves to be seasonal, and planned as such rather than improvised mid-incident. A B2B integration might warrant a looser upstream allocation during a partner's major platform release or a known end-of-quarter traffic spike, and a tighter one during otherwise calm months. Document that shift ahead of time. Don't invent the exception in the middle of a war room.

The payoff of doing this split correctly: when the upstream bucket is empty but the internal bucket is still mostly full, the data has already made the call. That's a vendor conversation, not a two-week engineering sprint, and nobody has to argue about it after the fact.

Burn rate alerting configured for upstream failure patterns

Threshold alerts and third-party dependencies do not get along. Upstream failures tend to arrive in bursts, a spike of 500 errors for four minutes that clears up on its own before anyone's even opened the dashboard. Set a plain threshold alert and it'll fire on that blip, then again on the next one, and eventually the on-call engineer starts muting the channel. That's the exact moment a real sustained outage sneaks through unnoticed.

Burn rate fixes this by measuring speed, not just level. At a 99.9% SLO with its 43.2-minute monthly budget, a burn rate of 1x means the budget is disappearing at the expected pace, nothing alarming. A burn rate of 14.4x means that same budget is gone in about two days. That's the number that should wake somebody up.

The Google SRE Workbook's multi-window, multi-burn-rate method solves the false-alarm problem cleanly: only page when a short window and a long window agree something's actually wrong. A quick blip clears the short window fast and never touches the long one, so it never pages. A real, sustained upstream degradation shows up on both, and that's when it should. A reasonable rule of thumb for sizing these windows: make the short one substantially smaller than the long one, so transient blips can clear before both windows agree.

• The fast window catches the acute stuff: a total upstream outage, sudden and unmissable.
• The slow window catches the slow burn: creeping latency, a gradually rising error rate, the kind of degradation that doesn't announce itself.

Whatever fires needs to say, right in the alert, whether the burning events are tagged upstream or internal. That's the very first decision an on-call engineer has to make, escalate to the vendor or start digging internally, and the alert should answer it before a human has to.

One case worth citing as a sense of scale: a trading API integration at BitFlyer replaced 47 arbitrary threshold alerts with 6 SLO-based burn rate alerts spanning availability, latency, and error rate. Alert volume dropped 73%, and mean time to resolution improved 45%. Fewer alerts, better signal, faster fixes. That's the whole pitch for burn rate alerting in one sentence.

Error budget policy decisions that account for upstream risk

Most error budget policies follow a familiar tiered structure, and it's a reasonable starting point for internal reliability work:

• Above 50% remaining: ship at normal speed.
• 25 to 50%: tighten review, hold off on the riskier changes.
• 10 to 25%: freeze new features, focus entirely on reliability.
• Below 10%: all hands on deck, nothing new gets shipped.

Apply that same freeze automatically when a vendor outage is what burned the budget, and the policy stops making sense. Punishing an engineering team for a payment processor's bad Tuesday doesn't fix anything, and it teaches the whole org that the policy is arbitrary theater rather than a real mechanism.

The fix is differentiating by cause, not just by remaining percentage:

• Budget burned by internal changes: the standard tiers apply exactly as written. That's the tradeoff the policy exists to enforce.
• Budget burned by upstream degradation: this triggers a vendor conversation, a review of fallback coverage and circuit breaker behavior, and a documented exception. Not an automatic freeze.
• Budget burned by a mix of both: require SRE sign-off on any change touching that integration path until the attribution tagging sorts out who's actually responsible.

The real value of a written policy is cultural, and it's easy to undersell. It turns "reliability should be the priority right now" from one engineer's opinion into an organizational fact nobody gets to argue with, because the data already settled it. That only works if the policy is written down, agreed to ahead of time, and actually enforced when the moment comes, not renegotiated under pressure by whoever's in the room.

According to isdown.app's analysis of error budget maturity, it usually takes exactly one instance of actually stopping a ship for the whole culture to take the policy seriously. Everything after that first time gets a lot easier to enforce.

Whatever the policy says, it belongs in the same document as the SLO target and the SLI definitions, tiers, triggers, escalation paths, all of it. A separate runbook is a runbook that goes stale the first time someone updates the SLO and forgets to update the other document too.

Escalation and vendor accountability when the upstream is the problem

When the upstream is the one bleeding the error budget, the fix isn't an engineering sprint, it's a documented conversation with the vendor, backed by the exact data the attribution tagging has been collecting all along. That data is the whole point of building this system in the first place.

Walking into a vendor escalation with "your API felt slow this week" gets nowhere. Walking in with a specific burn rate, a percentage of the monthly budget consumed by their outages, and timestamps tied to their own status page entries turns a vague complaint into a documented pattern. Vendors respond to patterns. They deflect vague complaints, because vague complaints are easy to deflect.

This is also where the earlier work on mitigation architecture, fallbacks, caching, circuit breakers, pulls double duty. It's not just an engineering safety net—it's leverage in the vendor conversation. A team that can point to "our circuit breaker already caught this, here's the exposure we still can't cover" is negotiating from a position that isn't just "please fix your API."

SLA credits from the vendor almost never map cleanly onto the actual cost of the incident. A vendor might issue a service credit worth a fraction of their monthly fee, while the internal error budget for that same incident is already gone and the customer-facing SLO has been blown for the month. That mismatch isn't a bug in the framework, it's the reason internal SLOs need to sit below external SLAs in the first place: the internal target is what actually protects the product, not the vendor's contract math.

None of this is a one-time exercise. Upstream reliability drifts, sometimes for the better after a vendor invests in their own infrastructure, sometimes for the worse after an acquisition or a platform migration nobody warned customers about. The review date attached to every SLO, the one from standard SRE guidance, is what keeps the target honest as that drift happens. Skip the review, and the SLO quietly turns into fiction while everyone keeps reporting against it as if it still means something.