What an SLA Actually Guarantees — and What It Doesn't

When a vendor quotes you a 99.9% uptime SLA, the number creates a feeling of commitment that the actual contract often doesn't support. 99.9% uptime means 8.7 hours of allowed downtime per year. But the vendor usually defines what counts as “downtime,” and those definitions frequently exclude scheduled maintenance, degraded performance that doesn't reach a full outage, issues caused by customer configuration, and problems affecting only a subset of services. The actual effective uptime that the SLA protects is often substantially less than what the headline number suggests.

The remedies are equally misleading. Most SLA credits are 10–25% of the monthly fees for the affected service during the outage period. You typically have to file a claim to receive them. They're issued as credits against future invoices, not cash refunds. And they're usually capped at one month's fees regardless of the duration or impact of the outage. If you're paying a vendor $5,000 per month and a day-long outage costs your business $50,000 in direct and indirect impact, the SLA credit mechanism will compensate you somewhere between $500 and $1,250. That's not compensation; it's a gesture.

This doesn't mean SLAs are worthless. They're useful as a signal of the vendor's commitment to reliability and as a basis for the conversation when things go wrong. But their primary value is as a benchmark for holding vendors accountable, not as meaningful financial protection against the business impact of serious incidents. Understanding this distinction changes how you evaluate vendors: you care less about the SLA percentage and more about the vendor's actual reliability track record and how they behave during incidents.

The definition of “uptime” in an SLA is doing a lot of work that the headline number doesn't reveal. Some vendors define availability as “the application returns a 200 response to a health check endpoint,” which means the application is technically “up” even if major features are broken. Others define it as availability of specific named services, measured at the API level, which is more meaningful. Read the definition carefully: “availability” should mean your users can use the application for its core purpose, not that a monitoring endpoint returns a success code.

The excluded categories in a typical SLA are extensive. Scheduled maintenance windows are almost universally excluded — read how much notice the vendor gives for scheduled maintenance and how often they use it. Force majeure clauses exclude outages caused by events outside the vendor's control, which can be defined broadly enough to include significant cloud provider incidents. Customer-caused issues are excluded, which is reasonable but can be used broadly to shift blame for borderline incidents. And issues with the vendor's upstream dependencies — the cloud provider their infrastructure runs on, third-party APIs they rely on — are typically excluded even though your users experience the impact the same way.

Credits require you to file a claim. This sounds minor but in practice means: you have to notice the outage, document it, calculate the credit you're owed, submit a claim within the specified window (often 30 days from the incident), and wait for the vendor to approve it. Many SLA credits go unclaimed simply because customers don't have a process for monitoring and claiming them. If SLA credits are part of your vendor relationship, assign someone to track incidents and file claims.

The first question is: what counts as downtime, and what's excluded? Read the SLA definition section, not just the uptime commitment. If the definition excludes scheduled maintenance and the vendor does weekly maintenance windows at 2am, you need to know how long those windows typically run and whether they're actually at 2am in your users' time zones. If the definition excludes “degraded performance,” ask what their threshold for declaring an incident versus logging it as degraded performance is.

The second question is: how do I claim a credit, and how long does it take? The credit mechanism exists to align incentives, not to compensate for actual business impact. If the process is burdensome, credits go unclaimed and the mechanism doesn't work. A vendor with a straightforward, automatic credit process (where credits are calculated and applied without you filing a claim) is demonstrating that they stand behind the commitment. A vendor whose credit process requires three forms of documentation and a formal dispute process is telling you something about how they handle accountability.

The third question is the most important: what is the actual business impact if this vendor is down for four hours, and is the credit I'd receive proportionate to that impact? For most vendors, the answer is no — the credit is a small fraction of the business impact. That's not the vendor's fault; it's the nature of the product category. But it means your actual risk management for critical vendors shouldn't rely on SLA credits — it should rely on resilience design, fallback options, and choosing vendors with demonstrated reliability rather than vendors with generous SLA language.

The math behind common SLA tiers: 99.9% uptime allows 8.7 hours of downtime per year, or about 43 minutes per month. 99.95% allows 4.4 hours per year, 22 minutes per month. 99.99% allows 52 minutes per year, 4.4 minutes per month. 99.999% (five nines) allows 5.2 minutes per year. Each additional nine requires substantially more engineering investment to achieve, which is why pricing escalates sharply between tiers and why most SaaS products offer 99.9% rather than 99.99%. The difference between 99.9% and 99.99% is the difference between building a service that tolerates failures and one that must almost never fail — these are architecturally different products.

The three things that matter more than the SLA percentage are incident response time commitments, whether the vendor has a public status page, and their historical performance against the SLA. Incident response time commitments tell you how long you'll be in the dark during an incident before the vendor acknowledges it and begins communicating. A public status page means you can monitor their incident history independently — before you sign a contract, look at the status page history for the past 12 months. What you see is more informative than any contractual commitment. Historical SLA performance is the most predictive: ask for their actual uptime measurements over the past year, not just the contractual commitment.

For critical vendors, build your resilience on top of their reliability rather than in place of it. This means designing for graceful degradation: what does your product do when this vendor is unavailable? Can you queue requests and process them when the vendor recovers? Can you display cached data while the vendor is down? Can you route around the vendor for a subset of critical functionality? A vendor with a 99.9% SLA and a product that degrades gracefully during that 0.1% is more operationally resilient than a vendor with a 99.99% SLA and a hard dependency that takes your product down entirely when they have an incident.