Setting a Realistic SLO with Third-Party Dependencies

A 99.99% SLO sounds ambitious. But if your stack depends on Stripe, an RDS database, and a CDN, your theoretical ceiling is already below 99.93% — before you've written a single line of your own code. Knowing this ceiling is the starting point for any honest SLO.

SLA ≠ SLO

An SLA (Service Level Agreement) is a contractual promise from a vendor to you, with financial penalties if violated. An SLO (Service Level Objective) is your internal engineering target. The SLO must always be stricter than the SLA: if you wait for an SLA violation to react, your users have already been suffering for a while. A 99.9% SLA tolerates 8.7h of downtime per year — you can't afford to wait for that.

The product law

The availability of a service chain is the product of the individual availabilities. If your payment flow depends on Stripe (99.99%), your RDS database (99.95%), and an internal API (99.9%), the composite availability is 0.9999 × 0.9995 × 0.999 = 99.84%. That's your theoretical ceiling — assuming failures are independent. In reality, they often aren't.

The safety margin

Never target your exact theoretical composite availability. You need a margin to absorb your own bugs, deployment windows, and correlated failures (two providers in the same AWS region failing together). A 10% margin is a good starting point: if your composite is 99.9%, target 99.81%. This leaves room to manoeuvre without violating your SLO on every minor incident.

Hidden dependencies

Teams often forget: the DNS resolver (if your DNS goes down, everything goes down), the CDN edge (for static assets but often also for the API), the OAuth provider (if you use Google SSO, a Google outage = users can't log in), and the cloud region itself. An AWS region outage can simultaneously affect your RDS database, your lambdas, and your SaaS providers hosted in the same region.