99.999% Uptime SLA: Five Nines Downtime per Year

Name: Uptimehub
Brand: Uptimehub
Price: 9.00 USD

In short

99.999% uptime, usually called five nines, allows 26 seconds of downtime in a calendar month and 5 minutes 15 seconds across a full year. Per day that is under one second. It is the only availability tier that cannot be reached by making a single system more reliable, because two components each running at 99.999% already multiply down to 99.998% when one depends on the other. Every published five nines SLA on the market is therefore a multi-region commitment: AWS sells it on DynamoDB global tables, Azure on multi-region Cosmos DB, Google on multi-region Spanner, and all three sell the single-region version of the same product at 99.99%.

// 99.999% ALLOWANCE

Exact figures

How much downtime 99.999% uptime allows, per period

Every figure below is the length of the period multiplied by 0.00001. The month appears four times deliberately, because contracts define a month differently and at this level the spread between February and a 31 day month is 2.6 seconds, which is a tenth of the whole budget.

Period	Downtime allowed at 99.999%	What that is in practice
Per hour	0.04 seconds	Shorter than a single TCP handshake across the Atlantic
Per day	0.86 seconds	Less than one second, every day, all year
Per week	6 seconds	One failed health check and the week is gone
Per 28 day month	24.2 seconds	February, the tightest month you get measured on
Per 30 day month	25.9 seconds	The convention most SaaS contracts use
Per 31 day month	26.8 seconds	The most generous calendar month
Per calendar-average month	26.3 seconds	A 365 day year divided by twelve
Per quarter	1 minute 19 seconds	Roughly one container restart, per quarter
Per year	5 minutes 15 seconds	One coffee break, spread across twelve months

Twenty-six seconds is the number that reframes the whole conversation. At 99.9% you have forty-three minutes a month, which is a window: someone can be paged, look at a graph and act. At 99.95% you have twenty-one minutes, still a window. At 99.99% you have four minutes and the window has closed. At 99.999% there is not even time for a health check to fail twice and a load balancer to notice.

That is why the annual figure is the more honest one to quote. Five minutes and fifteen seconds a year is not a monthly operating allowance, it is a statement that you expect roughly zero incidents and are budgeting for one very short one. For the same arithmetic at any other target, including working backwards from the seconds you were actually down, the uptime calculator runs it in both directions from 90% to 99.9999%.

// WHO PUBLISHES IT

Verified commitments

Which cloud providers actually commit to 99.999% uptime

Every figure in this table was read from the vendor's own SLA or documentation in August 2026. One pattern runs through all of it, and it is the single most useful thing to know about five nines: not one of these commitments applies to a single-region deployment.

Provider	Service and configuration	Committed uptime	The condition attached
Amazon Web Services	DynamoDB global tables, across multiple regions	99.999%	You must make reasonable attempts to fail over yourself for the higher tier to apply
Amazon Web Services	DynamoDB, a single region	99.99%	The same database engine, one region, one nine less
Microsoft Azure	Cosmos DB, reads across two or more regions	99.999%	Committed regardless of which consistency level you choose
Microsoft Azure	Cosmos DB, multi-region with multi-write enabled	99.999%	Multi-region with relaxed consistency but a single write region stays at 99.99%
Microsoft Azure	Cosmos DB, a single region	99.99%	Again, one nine is the price of the second region
Google Cloud	Spanner, multi-region and dual-region configurations	99.999%	Google states this explicitly as greater than what regional configurations provide
Google Cloud	Spanner, regional configurations	At least 99.99%	Written as a floor rather than a fixed figure

Three different companies, three different database engines, and the same pricing structure in all three: the single-region product is 99.99% and the multi-region product is 99.999%. AWS sells DynamoDB at 99.99% and DynamoDB global tables at 99.999%. Microsoft sells single-region Cosmos DB at 99.99% and commits to 99.999% for reads once an account spans two or more Azure regions. Google states that Spanner regional configurations are at least 99.99% while multi-region and dual-region configurations are 99.999%.

Read that as an engineering statement rather than a pricing one. Three organizations with more operational data than anyone else have independently concluded that one region cannot be made to deliver five nines, and that the only way to sell the number is to make the failures independent. The arithmetic in the next two sections is why.

The AWS wording deserves one extra note. The DynamoDB global tables commitment applies where the customer makes reasonable attempts to fail over during a single-region availability issue. That is a reasonable condition for a multi-region product, but it does mean the five nines is shared between vendor and customer rather than delivered to a passive one. Whoever is on the hook for triggering that failover needs the tooling and the runbook to do it, which is the same problem multi-location monitoring exists to solve on the detection side.

// SERIAL CHAIN

The arithmetic

Why a chain of five nines components is not a five nines system

When a request has to pass through several components in sequence, and any one of them failing means the request fails, the availabilities multiply. The composite is always lower than the weakest link, and it drops faster than most people expect. Each column below is the same per-component figure raised to the number of hops.

Each component	Also called	1 hop	3 hops	5 hops	8 hops
99.99%	Four nines each	99.990%	99.970%	99.950%	99.920%
99.995%		99.995%	99.985%	99.975%	99.960%
99.999%	Five nines each	99.999%	99.997%	99.995%	99.992%
99.9999%	Six nines each	99.9999%	99.9997%	99.9995%	99.9992%

Read the five nines row first, because it contains the fact that settles the argument. Two components each running at 99.999%, one depending on the other, produce a composite of 99.998%. You have already fallen out of five nines with two perfect parts and nothing has gone wrong yet. By ten hops the same parts give you 99.99%, which is four nines, one full tier down.

Now read the four nines row, because it is the one that describes real systems. A request that touches a CDN, a load balancer, an application server, a cache, a database and an authentication service has six hops. At 99.99% each, the composite is 99.94%. That is worse than 99.95%, and it is the ceiling before your own code has done anything wrong. Teams often discover this after months of work on individual services, which is the expensive way to learn that the count of dependencies matters more than the quality of any one of them.

Two caveats keep this honest. The multiplication assumes failures are independent, and in a single region they frequently are not, since a power event or a network partition takes several components at once. That correlation makes the real figure worse than the table, not better. It also assumes every component is genuinely on the critical path. A recommendations service that can fail without breaking checkout is not a hop, and the fastest route to a higher composite is usually to move components off the path rather than to make them more reliable.

The table and the tool above both assume every component sits at the same availability, which is the right simplification for reasoning about five nines specifically. Real stacks are uneven: a CDN at 99.99%, an application tier at 99.95% and a database at 99.99% are three different numbers. To compose a mixed chain component by component, and to see what a provider owes you in service credits when one of them misses its commitment, the SLA calculator takes each dependency separately.

// REDUNDANCY

The other direction

How redundancy buys nines that better components cannot

Where serial dependencies multiply availability downward, independent copies multiply unavailability downward, which is far more powerful. Two copies of a component fail together only when both fail at once, so the combined failure rate is the product of the two. This is the mechanism behind every published five nines SLA.

One component	Downtime per year	Two independent copies	Downtime per year	Three independent copies	Downtime per year
99%	3d 15h 36m	99.99%	52m 34s	99.9999%	31.5s
99.5%	1d 19h 48m	99.9975%	13m 8s	99.999988%	3.9s
99.9%	8h 45m 36s	99.9999%	31.5s	99.9999999%	0.03s
99.99%	52m 34s	99.999999%	0.32s	Beyond nine nines	Unmeasurable

The 99.9% row is the one worth staring at. A component that is down for eight hours and forty-six minutes a year is unremarkable, the kind of thing a mid-tier managed service delivers. Run two of them independently and the pair is down for thirty-one seconds a year, which is six nines. You did not buy better components. You bought a second ordinary one and made sure it fails for different reasons.

The word doing all the work in that sentence is independently. The arithmetic collapses the moment the copies share a failure mode: the same rack, the same power feed, the same availability zone, the same deployment pipeline pushing the same bad config to both at once, the same expired certificate. Shared-fate redundancy gives you the cost of two systems and the availability of slightly more than one. This is exactly why the hyperscalers put their five nines commitments behind a region boundary rather than behind a second instance, and it is why a certificate expiry check matters more than its cost suggests: a certificate expiring is a correlated failure that takes every copy down at the same second.

Combine the two tables and you have the design rule. Shorten the serial chain, then duplicate what is left across independent failure domains. A path of three components at 99.9% each with two independent copies of each reaches roughly 99.9997%, comfortably inside five nines, using parts that individually would not qualify for a 99.95% commitment.

// EVERY LEVEL

In context

99.99% vs 99.999% vs 99.9999% uptime

Each nine divides the allowance by ten. Every month figure below is on a 30 day month and every annual figure on a 365 day year, so the columns are directly comparable.

Uptime SLA	Also called	Per 30 day month	Per year	Where you see it
99%	Two nines	7h 12m	3d 15h 36m	No published SLA, or an internal tool
99.5%		3h 36m	1d 19h 48m	Single-instance cloud compute, budget hosting
99.9%	Three nines	43m 12s	8h 45m 36s	The default commercial SaaS promise
99.95%	Three and a half nines	21m 36s	4h 22m 48s	Paid business tiers and managed databases
99.99%	Four nines	4m 19s	52m 34s	Multi-zone enterprise infrastructure
99.999%	Five nines	25.9s	5m 15s	Multi-region databases, payments, telecoms
99.9999%	Six nines	2.6s	31.5s	Effectively unmeasurable outside the system itself

The steps are uniform on paper and wildly uneven in practice. Going from 99.9% to 99.95% uptime is usually bought with faster detection and a rehearsed runbook. Going from 99.95% to 99.99% uptime has to be bought with automated failover, because four minutes is less than a human response cycle. Going from 99.99% to 99.999% has to be bought with a second region, because twenty-six seconds is less than a failover.

Six nines is on the table for completeness rather than because anyone should target it. At 2.6 seconds a month the allowance is shorter than a TCP retransmission timeout, and it appears in component datasheets and redundancy calculations rather than in contracts. If you are choosing a level rather than reading one, what counts as a good uptime percentage compares them by what each costs to run, and error budgets covers spending the allowance deliberately instead of discovering it is gone.

// DETECTION FLOOR

Measurement

Why no external monitor can verify 99.999% uptime

A monitor that checks every N seconds has an average detection latency of N divided by two, and cannot record an outage shorter than one interval at all. At five nines the entire monthly budget is about 26 seconds, which is smaller than the detection latency of every commercial monitoring plan sold, including ours.

Check interval	Average time to detect	Share of the monthly 99.999% budget spent detecting one outage	Can it verify five nines?
Every 5 minutes	150 seconds	570%	No. One average detection is twenty-two months of budget
Every 60 seconds	30 seconds	114%	No. One average detection exceeds the entire month
Every 30 seconds	15 seconds	57%	No. Two detections in a year would break it
Every 15 seconds	7.5 seconds	29%	No. Still spends over a quarter of the month per detection
Every 1 second	0.5 seconds	1.9%	Arguably, but no commercial external monitor runs at this rate

This is worth saying plainly, including by a company that sells monitoring. Uptimehub checks every thirty seconds from six regions, which is fast enough to hold a 99.95% or 99.99% figure honestly, and it is not fast enough to certify five nines. Nothing sold externally is. The detection latency alone is bigger than the number you are trying to prove, so an external monitor reporting 100.000% for a month is telling you it saw nothing, not that nothing happened.

Five nines claims come from inside the system instead. You count successful responses against total responses at the load balancer or the service mesh, over millions of requests, and the availability figure falls out of the ratio with enough resolution to be meaningful. That is a fundamentally different measurement: request-weighted rather than time-sampled, and it can see a four second blip that no external prober will ever catch.

External monitoring still earns its place next to that, for two reasons an internal counter cannot cover. It sees the parts of the path your own instrumentation sits behind, which means DNS, the CDN, the TLS handshake and the route between the user and your edge. And it is independent, which is the entire point when the question is contractual rather than operational, since a vendor grading its own homework is not evidence. Treat one as the number and the other as the witness. Keeping that history in a form a customer will accept is what SLA monitoring is for, and publishing it in the other direction is what a status page does.

// LIVE CHECK

Measure it

Check what your service is doing right now

Whatever tier you are actually committed to, it is a claim until something independent is watching it. Run a live check on any URL below, then set up continuous monitoring at 30 second intervals from six regions.

ms

timeout

Latency scope · live

Uptime · 30 days

ms

Avg response

Checked from regions with auto-retry. No single-location false alarms.

All systems operational. Steady pulse across every region.

Down · caught in 8s

api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.

Resolved · 4m 12s downtime

api.example.com is back up. The incident is logged to your status page history automatically.

Example, Inc. Status

Operational

90-day uptime · branded · your domain

Live demo · drive it, no signup needed

// 6 REQUIREMENTS

Reality check

What it takes to actually hold 99.999% uptime

None of these are about working harder, and that is the point. Five nines is a property of the design. If the design does not have it, no amount of operational discipline will produce it.

01

Redundancy that fails independently, in more than one region

This is the whole game, and the published SLAs prove it. AWS, Azure and Google all sell the single-region version of their flagship database at 99.99% and the multi-region version at 99.999%. The extra nine is not better engineering inside one datacenter, it is a second datacenter that fails for unrelated reasons. Two independent components at 99.9% each combine to 99.9999%, which is better than five nines from parts that individually are not close.

02

Failover with no human in the loop

Twenty-six seconds a month is less time than it takes to read a pager notification. There is no version of five nines where somebody is woken up, opens a laptop and fixes something. Detection, decision and traffic shift all have to be automatic, and the failover path has to be exercised often enough that you know it works, because the first time you run it will otherwise be during the incident.

03

A critical path short enough to survive the multiplication

Availability multiplies along a serial dependency chain. Six components at 99.99% each produce a composite of 99.94%, which is worse than three nines and a half. To reach five nines composite you either need every component at roughly six nines, or you need fewer components, or you need each one duplicated. Counting the hops in your critical path is usually more informative than measuring any single one of them.

04

Deploys that cannot take the service down at all

A release that drops connections for ten seconds has spent 38% of the month. There is no safe deployment window at this level. Five nines architectures ship behind load balancers that drain connections, with health-gated rollouts and instant rollback, and they treat a deploy that causes any user-visible error as an incident rather than as a cost of doing business.

05

Internal instrumentation, because external checks cannot see this

The monthly budget is shorter than the gap between checks on every commercial monitoring plan sold. A thirty second monitor cannot report a twenty second outage, and its own detection latency is larger than the number you are trying to measure. Five nines is claimed from request-level telemetry inside the system, counting successful responses against total responses. External monitoring still matters, but as an independent second opinion on whether the service is reachable, not as the source of the percentage.

06

A definition of down that you can defend

At 26 seconds a month, the definition does more work than the engineering. Is a request that takes eight seconds available? Is one region serving stale reads available? Is a partial feature outage available? Most five nines claims survive because the definition is narrow, and most five nines disputes are about the definition rather than about the arithmetic.

Before committing to any of this, be sure the target is the one you need. Five nines costs several times what four nines costs, and the difference between them is under four minutes a month. For most businesses that four minutes has no measurable revenue attached, and the same budget spent on faster recovery, better alerting or a genuinely tested backup path buys more resilience than the extra nine does. The tier is right for payment authorization, emergency services, telecom signalling and shared infrastructure other people build on. It is usually wrong for an application.

// 5 THINGS TO CHECK

Read the contract

What a 99.999% uptime SLA quietly leaves out

The arithmetic on this page is exact. What a contract chooses to measure is a negotiation, and at 26 seconds a month the definition matters more than at any other tier.

01

Nobody sells five nines on a single region

This is the most useful sentence on the page if you are evaluating a vendor. Every five nines commitment we could verify from a primary source in August 2026 was conditional on a multi-region deployment: DynamoDB global tables, Cosmos DB across two or more Azure regions, Spanner multi-region and dual-region. All three vendors sell the identical single-region product at 99.99%. If a supplier offers you five nines without describing a multi-region topology, ask what the number is measured on.

02

The customer often carries part of the obligation

AWS words the DynamoDB global tables SLA so that the higher tier applies when you make reasonable attempts to fail over during a single-region issue. That is a fair condition, but it means the five nines is a joint commitment rather than something the vendor delivers to a passive customer. Read who is responsible for triggering the failover before you rely on the headline.

03

A single one minute incident ends the year, not the month

Sixty seconds of downtime is 228% of the monthly allowance and 19% of the entire annual one. Five minutes spends 95% of the whole year in one sitting. This changes how the target has to be managed: at 99.9% you spend the budget gradually, at 99.999% you either have zero incidents or you have missed, and there is no middle where you are running slightly hot.

04

Measured monthly, five nines is far harder than measured annually

An annual 99.999% gives you 5 minutes 15 seconds and lets one bad thirty seconds in March be absorbed. A monthly 99.999% resets to 26 seconds twelve times, and one bad month cannot be repaid by eleven perfect ones. The percentages read identically in a contract. Check the measurement window before you agree to either.

05

Credits at this level are symbolic

The published remedies are not scaled to the promise. AWS pays 10% of the DynamoDB bill for a month below 99.99%, 25% below 99.0% and 100% below 95.0%. Missing five nines by a wide margin, say a month at 99.95%, still lands in the 10% band. Nobody chooses five nines infrastructure for the credits, and you should not price the risk as though the credit covers it.

If you are buying, the useful question is not whether the vendor publishes five nines. It is what topology the number applies to, who has to act during a regional failure, and what counts as down. If you are selling, the useful question is whether your dependency chain can even reach the figure, which the calculator at the top of this page will answer in about ten seconds. A commitment your architecture caps below is a liability, not a differentiator.

// QUESTIONS

FAQ

Questions people ask about 99.999% uptime

99.999% uptime means a service may be unavailable for 0.001% of the measured period. In a calendar month that is 26 seconds, and across a 365 day year it is 5 minutes 15 seconds. It is called five nines, and in practice it is a claim about architecture rather than about effort: it requires redundancy across regions, because no single deployment recovers from anything in 26 seconds.

It means 25.9 seconds of downtime in a 30 day month, 26.3 seconds if the month is defined as a 365 day year divided by twelve, and 5 minutes 15 seconds over a full year. Per day the allowance is 0.86 seconds and per week it is 6 seconds. Per quarter it is 1 minute 19 seconds.

0.43 minutes per month and 5.26 minutes per year. In seconds that is 25.92 a month on a 30 day basis and 315.36 a year. Expressed the other way round, a five nines service must be available for 8,759.91 hours out of the 8,760 hours in a year.

0.0876 hours, which is 5 minutes 15.36 seconds. Per month it is 0.0072 hours, or roughly 26 seconds. Hours is an awkward unit at this level, which is itself a useful signal: once the allowance is easier to state in seconds than in hours, you are past the point where operational response time can produce the number.

A factor of ten. 99.99% allows 4 minutes 19 seconds a month, 99.999% allows 26 seconds. The gap is not incremental, it is architectural. Four nines can be met with a multi-zone deployment inside one region and automated restarts. Five nines requires a second region that can serve traffic on its own, which is why every hyperscaler prices the two tiers as different products.

It is realistic for a narrow, well-defined service running across independent regions, and unrealistic for most applications as a whole. The arithmetic is the reason: a critical path of six components at 99.99% each has a composite ceiling of 99.94%, well short of five nines, no matter how good each component is. Teams that reach it do so by shortening the dependency chain and duplicating what remains, not by trying harder.

Multiply the period length by 0.00001. A 30 day month is 2,592,000 seconds, so the allowance is 25.92 seconds. A 365 day year is 31,536,000 seconds, giving 315.36 seconds, or 5 minutes 15 seconds. To check a period you already ran, take total seconds minus downtime seconds, divide by total seconds, then multiply by 100.

AWS commits to 99.999% for DynamoDB global tables, Microsoft commits to 99.999% for Cosmos DB read availability across two or more regions and for multi-region multi-write accounts, and Google commits to 99.999% for Spanner multi-region and dual-region configurations. In all three cases the single-region version of the same service is sold at 99.99%, so the extra nine is bought with a second region rather than with a better one.

Not from outside the system. The monthly budget is about 26 seconds, and a monitor checking every 30 seconds has an average detection latency of 15 seconds, which is 57% of the entire budget before the outage itself is counted. Even one second checks spend 1.9% per detection. Five nines is measured from internal request telemetry, with external monitoring used as an independent check on reachability rather than as the source of the figure.

Five nines availability is another name for 99.999% uptime, so called because the figure contains five nines. It permits 26 seconds of unavailability a month and 5 minutes 15 seconds a year. The term comes from telecoms, where carrier-grade switching equipment was specified at this level, and it has carried over to distributed databases and payment infrastructure.

On a 30 day month, 25.92 seconds. On a 31 day month, 26.78 seconds. On February with 28 days, 24.19 seconds. Contracts defining a month as a 365 day year divided by twelve give 26.3 seconds. The spread across month lengths is about 2.6 seconds, which is a tenth of the whole budget, so the basis is worth pinning down in writing.

Six nines allows 2.6 seconds a month and 31.5 seconds a year, a tenth of five nines again. At that point the allowance is shorter than a single TCP retransmission timeout, and the number stops describing something you can operate towards. Six nines appears in component datasheets and in redundancy arithmetic rather than in commercial SLAs, because no vendor will sign a contract measured in single-digit seconds.

Last updated August 2026

// RELATED

Keep reading

Where to go from here

The tier below this one is covered in full on 99.99% uptime, including why a five minute monitor cannot verify four nines either, and the half step under that on 99.95% uptime, which is where most paid business plans actually stop. Three nines, still the default commercial promise, is on what 99.9% uptime means. To run the arithmetic on any target, including backwards from the seconds you were down, use the uptime and SLA calculator. On the tooling side, the uptime monitoring tools comparison rates thirteen tools by check interval and region count, and the uptime monitoring pricing comparison shows what each charges. If the commitment sits on an API rather than a website, API monitoring tools and the API response time benchmarks are the better starting point, since an endpoint answering in twenty seconds counts as available in every SLA on this page.

99.999% Uptime: What Five Nines Availability Means in Minutes per Month and Hours per Year