What a 99.99% SLA actually commits your provider to

TL;DR: 99.99% allows about 4.4 minutes of downtime per month. The real questions are: measured over what window, excluding what, applied to what scope, remedied by what, and detected by whom. An SLA is only as strong as its weakest definition.

Every managed database provider advertises an availability number, and most buyers read it as a promise. It is not a promise.

It’s actually a formula, and the formula's variables live in the fine print. Two providers advertising "99.99%" can be committing to radically different things. This article decodes the number itself, then the six clauses that determine what it is worth.

First, the raw math

Availability | Downtime allowed per month | Per year

99% ~7.3 hours ~3.7 days

99.9% ~44 minutes ~8.8 hours

99.95% ~22 minutes ~4.4 hours

99.99% ~4.4 minutes ~53 minutes

99.999% ~26 seconds ~5.3 minutes

Two observations. The jump from 99.9% to 99.99% is the expensive one: it is the difference between "an incident can be handled by whoever is on call" and "the system must survive incidents without humans in the loop."

And anything above 99.99% as a blanket promise deserves skepticism: five nines allows 26 seconds a month, which is less than most failovers take. Providers who print it casually are usually printing marketing.

The reason those 4.4 minutes matter is what a minute costs.

The ITIC 2024 Hourly Cost of Downtime study found hourly downtime now exceeds $300,000 for over 90% of mid-size and large enterprises, with 41% putting it between $1 million and $5 million+ per hour. At those rates the difference between three nines and four (roughly 40 minutes a month) is real money, which is why the clauses below are worth reading closely.

The six clauses that decide what the number means

1. The measurement window. 

Monthly windows reset the clock every 30 days: twelve separate 4.4-minute budgets. An annual window lets one bad afternoon consume the whole year's budget with no consequence for months of mediocrity afterward. Monthly is the buyer-friendly standard; check which one you are signing.

2. The exclusions list. 

The load-bearing clause. Common exclusions: scheduled maintenance (how many hours per month, announced how far ahead?), "emergency maintenance" (an exclusion that can absorb almost anything if undefined), failures attributed to your configuration or your cloud provider, and force majeure stretched to cover ordinary upstream outages. An SLA with an open-ended maintenance exclusion is an SLA on paper only. Ask: over the last 12 months, for a comparable client, how many minutes of downtime were excluded, and why?

3. The scope of "available." 

Does availability mean the instance responds to a ping, the engine accepts connections, or your workload serves queries within a latency bound? A database that accepts connections and times out every query is "available" under the first two definitions. Push for a definition tied to service, not process liveness.

4. Who detects, and who must report. 

If the burden is on you to detect, report, and claim within a deadline, the SLA is a rebate program, not an accountability instrument. The strong version is one where provider-side monitoring detects, provider reports proactively, and works with you on resolution.

5. The remedy. 

Service credits capped at a fraction of the monthly fee are the industry norm, and they are compensation theater relative to what an outage costs you. Credits will never make you whole; their real function is signaling. What you actually want the SLA to buy is behavior: a provider whose engineering practices treat the budget as real. Which leads to the last clause.

6. What happens after a breach. 

The strongest SLA clause is not the credit; it is the obligation that follows a miss: a root cause analysis delivered within a defined period, remediation actions with owners and dates, and termination rights after repeated breaches. A provider that resists the RCA obligation is telling you how incidents will go.

"Enforced end to end": what it should mean

When Maxima Consulting states a 99.99% uptime SLA enforced end to end, the operational meaning is: availability is measured at the service level, monitored by the provider's own follow-the-sun SRE teams (Kraków and Pune, 24/7/365), incidents trigger engineering follow-up rather than ticket closure, and every repeat incident is treated as a defect to be removed.

That operating model, not the number, is what the case history reflects: a global financial institution managing over $3 trillion in assets, running business-critical databases on this service for over ten years with zero major outages. It is also the argument in our earlier piece on achieving 99.99% reliability with a workload-first architecture.

The five-minute SLA audit for your current contract

Find your availability definition and check it against the six clauses:

• window (monthly?),
• exclusions (bounded and specific?),
• scope (service-level, not ping-level?),
• detection (provider-side, automatic credits?),
• remedy (credits plus RCA obligation?),
• breach consequences (termination rights?).

Score one point per buyer-friendly answer. Below four, the number on the cover page is decoration.

FAQ

How many minutes of downtime does a 99.99% SLA allow? 

About 4.4 minutes per month, or roughly 53 minutes per year, before exclusions. The exclusions list determines how much real-world downtime never counts against the budget.

Is a 99.999% SLA realistic? 

As a blanket promise, rarely. Five nines allows about 26 seconds of downtime a month, less than a typical failover event. It is achievable for specific, engineered-for workloads and should be phrased as a contracted outcome for those workloads, not a marketing banner.

What should a database SLA include besides the uptime number? 

Committed response and restore times per severity, a service-level (not ping-level) availability definition, a bounded exclusions list, provider-side detection with automatic credits, a root cause analysis obligation after breaches, and termination rights after repeated misses.

Do SLA credits actually compensate for an outage? 

No. Credits are typically capped at a fraction of the monthly fee, orders of magnitude below the business cost of a serious outage. Treat credits as an incentive-alignment signal and negotiate for the post-breach obligations instead.