99.99% Uptime: What 99.99% Availability Means in Hours per Year and Minutes per Month
Four nines gives you 4 minutes 19 seconds a month. This page has the exact allowance for every period, what it takes to hold, and the reason most monitoring cannot even measure it.
99.99% budget tracker
LiveAgainst the 99.99% budget
Four nines is 0.01% of the period. On a 30 day month that is 259.2 seconds. The month basis matters here: February is nearly 10% tighter than a 31 day month, and the contract decides which one you are held to.
In short
99.99% uptime, usually called four nines, allows 4 minutes 19 seconds of downtime in a 30 day month and 52 minutes 34 seconds across a full year. That works out to about 9 seconds a day and 1 minute a week. It is exactly ten times stricter than 99.9%, which permits 8 hours 46 minutes a year. Because nobody can acknowledge an alert, diagnose a fault and restore service inside four minutes, a genuine 99.99% target is met with automated failover, not with a fast on-call rota.
Exact figures
How much downtime 99.99% uptime allows, per period
Every figure below is the period multiplied by 0.0001. The month appears four times on purpose, because contracts define a month differently and at this level the difference is a meaningful slice of the whole budget.
| Period | Downtime allowed at 99.99% | What that is in practice |
|---|---|---|
| Per hour | 0.36 seconds | Effectively zero. Not a useful unit at this level |
| Per day | 8.6 seconds | One failed deploy that rolls back cleanly |
| Per week | 1 minute 0 seconds | A single container restart |
| Per 28 day month | 4 minutes 2 seconds | February, the tightest month you will be measured on |
| Per 30 day month | 4 minutes 19 seconds | The convention most SaaS contracts use |
| Per 31 day month | 4 minutes 28 seconds | The most generous calendar month |
| Per calendar-average month | 4 minutes 23 seconds | A 365 day year divided by twelve |
| Per quarter | 13 minutes 8 seconds | One incident, if it is a short one |
| Per year | 52 minutes 34 seconds | Less than a single lunch break, for the whole year |
The number people react to is the annual one. Fifty-two minutes and thirty-four seconds is the total unavailability a four nines service is allowed across an entire year, including every deploy, every database failover, every certificate renewal that went wrong and every time a cloud region had a bad afternoon. Written as a percentage it looks like a rounding error next to 99.9%. Written as a stopwatch it is the difference between one bad hour a year and one bad hour a month.
If you want the same arithmetic for any other target, the uptime calculator runs it in both directions for every level from 90% to 99.9999%, and what 99.9% uptime means covers the level directly below this one, which is where most SaaS products actually sit.
In context
99.9% vs 99.95% vs 99.99% vs 99.999% uptime
Each extra nine divides the allowance by ten. That is the entire relationship, and it is why the jump from 99.9% to 99.99% is not a ten percent improvement in engineering effort but something closer to a different architecture.
| Uptime SLA | Also called | Per 30 day month | Per year | Where you see it |
|---|---|---|---|---|
| 99% | Two nines | 7h 12m | 3d 15h 36m | No SLA published, or an internal tool |
| 99.5% | 3h 36m | 1d 19h 48m | Small business hosting | |
| 99.9% | Three nines | 43m 12s | 8h 45m 36s | The standard commercial SaaS promise |
| 99.95% | 21m 36s | 4h 22m 48s | Paid business tiers, common step-up | |
| 99.99% | Four nines | 4m 19s | 52m 34s | Enterprise contracts and managed infrastructure |
| 99.999% | Five nines | 26s | 5m 15s | Telecoms, payments, emergency systems |
A useful way to read that table is by what a single incident costs you. At 99.9%, a 40 minute outage spends most of one month and the year is fine. At 99.99%, the same 40 minute outage has spent 76% of your entire annual allowance, and every remaining month has to be perfect. Four nines is not really a target for average behaviour. It is a target for your worst day.
The row directly below is the one most teams should be looking at instead. 99.95% uptime gives you 21 minutes 36 seconds a month, which is long enough for a person to be paged and trigger a failover, and it is the highest level reachable without automating the recovery. That is also why teams operating at four nines plan against an error budget rather than a percentage. The budget framing makes the trade-off explicit: you have 259 seconds this month, shipping features spends some of it, and when it runs out the release freeze is automatic rather than argued about.
The part everyone skips
Your check interval decides whether 99.99% is measurable at all
A monitor cannot record an outage shorter than the gap between its checks. That is not a limitation of any particular tool, it is arithmetic. At four nines the budget is 259 seconds a month, so the check interval is not a settings detail, it is the resolution limit on the entire number you are promising.
| Check interval | Shortest outage it can record | Monthly 99.99% budget spent by one detection | Can it verify 99.99%? |
|---|---|---|---|
| Every 5 minutes | 5 minutes | 116% | No. A single failed check exceeds the entire monthly budget |
| Every 3 minutes | 3 minutes | 69% | No. One missed check spends two thirds of the month |
| Every 60 seconds | 60 seconds | 23% | Barely. Four detections in a month and the SLA is gone |
| Every 30 seconds | 30 seconds | 12% | Yes, with room to detect and recover inside the budget |
| Every 15 seconds | 15 seconds | 6% | Yes. The resolution most 99.99% contracts are audited at |
Read the top row again, because it is the one that catches people out. A free or entry-level monitor checking every five minutes reports a percentage that is arithmetically incapable of describing a four nines service. It will show you a clean 100% month that contained a three minute outage, and it will show you a breached month when a single check timed out on a slow network path. Neither number means anything at this level.
The second requirement is confirmation. A single probe having a bad thirty seconds is common, and at four nines one false positive is 12% of the month. Checking from several regions and requiring a second region to agree before an incident counts is what separates a measurable number from a noisy one. That is covered in more depth on multi-location monitoring, and the practical mechanics of turning detection into a response are on uptime monitoring.
Measure it
Find out what your service is actually doing right now
99.99% is a claim until something is watching. Run a live check on any URL below, then set up continuous monitoring at 30 second intervals from six regions if you want the figure tracked with enough resolution to defend it.
Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
Reality check
What it actually takes to hold 99.99% uptime
Nothing here is exotic. What makes four nines expensive is that all six have to be true at once, and any single one of them missing is enough to break the number over a year.
Redundancy at every layer, with no single primary
One database primary, one load balancer or one availability zone is enough to make 99.99% impossible to hold across a year. The arithmetic is unforgiving: a single component that fails once for twenty minutes has spent forty percent of your annual budget in one afternoon.
Failover that runs without a human decision
Four minutes and nineteen seconds a month is shorter than the time it takes to wake somebody, have them read the alert, open a laptop and find the right dashboard. If a person has to approve the recovery, the recovery is too slow. Automated health-check-driven failover is the only mechanism that fits inside the budget.
Deployments that cannot take the service down
Blue-green or rolling deploys with automatic rollback on error rate. A deploy that briefly drops connections is a normal, forgivable event at 99.9%. At 99.99% a thirty second blip during every weekly release consumes half the month before anything has actually gone wrong.
No maintenance windows, or a contract that excludes them
This is where published SLAs and reality diverge most. Many vendors advertise 99.99% and then exclude announced maintenance from the calculation, which means the number describes unplanned downtime only. Decide which one you are promising before you sign it, because your customers will assume the stricter reading.
Measurement fine enough to see the failures
You cannot commit to a budget you cannot observe. External checks at 30 seconds or better, from more than one region, with a second-region confirmation before an alert counts. A tool that looks every five minutes will report a clean month that contained a three minute outage nobody recorded.
Dependencies whose own numbers leave you room
Availability multiplies downward. A stack sitting on a 99.99% host, a 99.99% CDN and a 99.95% payment provider has a mathematical ceiling near 99.93%, which is below three and a half nines. You cannot promise 99.99% end to end on top of components that do not individually beat it.
The last point deserves the most attention when you are the one writing the SLA. Multiply the published availability of everything in your critical path: hosting, CDN, DNS, database, authentication, payments. Three components at 99.99% and one at 99.95% already caps you near 99.92%, which is below three and a half nines before your own code has done anything wrong. If you intend to publish four nines, every dependency needs to beat it, or you need redundancy that removes the dependency from the critical path entirely.
Read the contract
What a 99.99% uptime SLA quietly leaves out
The arithmetic on this page is exact. What a contract measures is a choice, and the gap between the two is where four nines disputes actually happen.
The measurement window changes the difficulty
A 99.99% target measured monthly is much harder than the same number measured annually. Monthly, you get 4 minutes 19 seconds and a bad month cannot be repaid. Annually, you get 52 minutes and one 40 minute incident in March can be absorbed by eleven clean months. Contracts that say 99.99% without naming the window are ambiguous in the vendor's favour.
Credits are capped and rarely worth claiming
The standard remedy is a percentage of the monthly fee for the affected service, usually tiered, usually capped somewhere between 10 and 100 percent of that month, and usually claimable only inside a short window after the incident. On a $500 monthly bill, breaching four nines might return $50. That is not compensation for an outage. It is a signal of engineering confidence.
Partial failure is often counted as full availability
Availability is normally a binary result from one request to one endpoint. A checkout that fails for one card processor, an API returning 500s on a single route, or pages loading in 25 seconds will usually be recorded as up. If your 99.99% matters commercially, define it on the transaction that makes money, not on whether the homepage returns a 200.
Single-region measurement hides regional outages
If availability is measured from one probe location, an outage affecting only European users may never enter the calculation. Multi-region checking is what makes a four nines figure honest rather than convenient, and it is also what stops a flaky probe from manufacturing a breach that never happened.
Rounding does a surprising amount of work
Uptime is often published to two decimal places, so 99.985% displays as 99.99%. Over a 30 day month that rounding conceals up to two extra minutes of downtime, which is nearly half the real budget. Ask what precision the reported figure uses before treating a dashboard number as contractual.
If you are buying rather than selling, the two questions worth asking before anything else are what the measurement window is and what the exclusions clause removes. A 99.99% annual SLA with maintenance excluded is a materially weaker promise than a 99.9% monthly SLA measured on everything, even though the headline number is ten times better. Our SLA monitoring page covers how to hold a vendor to whichever definition you agreed on, with your own independent measurement rather than theirs.
FAQ
Questions people ask about 99.99% uptime
99.99% uptime means a service is permitted to be unavailable for 0.01% of the measured period. In a 30 day month that is 4 minutes 19 seconds, and across a 365 day year it is 52 minutes 34 seconds. It is commonly called four nines and it is the level most enterprise infrastructure contracts are written at.
It means 4 minutes 19 seconds of downtime in a 30 day month, 4 minutes 23 seconds if the month is defined as a 365 day year divided by twelve, and 52 minutes 34 seconds over a full year. Per day it is about 8.6 seconds and per week about 1 minute.
99.99% uptime is 0.876 hours of allowed downtime per year, which is 52 minutes 34 seconds. Per month it is 0.072 hours, or 4 minutes 19 seconds on a 30 day month. Expressed the other way, a 99.99% service must be available for 8,759.12 hours out of 8,760 in a year.
One nine, which is a factor of ten in allowed downtime. 99.9% permits 43 minutes 12 seconds a month and 8 hours 46 minutes a year. 99.99% permits 4 minutes 19 seconds a month and 52 minutes 34 seconds a year. Operationally the gap is wider than the arithmetic: 99.9% is reachable with monitoring and an on-call engineer, while 99.99% requires redundancy and automatic failover.
It is very good, and for most web products it is more than they need. 99.99% is the right target when a few minutes of unavailability has a direct revenue or contractual cost, such as payments, trading, health systems or an API other companies build on. Below that threshold, 99.9% or 99.95% delivers most of the benefit at a fraction of the infrastructure cost.
Multiply the period by 0.0001. A 30 day month is 2,592,000 seconds, so the allowance is 259.2 seconds, or 4 minutes 19 seconds. A 365 day year is 31,536,000 seconds, giving 3,153.6 seconds, or 52 minutes 34 seconds. To check a month you actually ran, use uptime percent = (total minutes minus downtime minutes) divided by total minutes, times 100.
On a 30 day month, 4 minutes 19 seconds. On a 31 day month, 4 minutes 28 seconds. On February with 28 days, 4 minutes 2 seconds. Contracts that define a month as a 365 day year divided by twelve give 4 minutes 23 seconds. The differences are small in absolute terms but they are up to ten percent of the whole budget.
Four nines is shorthand for 99.99% availability, named for the four consecutive nines in the figure. Each additional nine divides the allowed downtime by ten, so three nines is 99.9%, four nines is 99.99% and five nines is 99.999%. Four nines allows 52 minutes 34 seconds of downtime a year.
Only if your checks run at least every 30 seconds. A monitor that checks every 5 minutes cannot record an outage shorter than 5 minutes, which is already more than the entire monthly budget at four nines. At 60 second checks a single detected failure consumes 23% of the month. Verification also needs confirmation from a second region so a network fault at one probe does not count as an outage.
The infrastructure cost roughly doubles compared with 99.9%, because it requires redundancy at every layer, multi-zone deployment, automated failover and monitoring fine enough to observe the budget. The larger cost is usually organisational: deployments must not cause downtime, maintenance cannot take the service offline, and every dependency has to publish a number better than the one you promise.
Many publish 99.99% for services deployed across multiple availability zones, and lower figures for single-zone deployments. Read two things before relying on it: whether the number applies to your specific deployment topology, and what the exclusions clause removes from the calculation. Announced maintenance is excluded far more often than buyers expect.
4.32 minutes per 30 day month and 52.56 minutes per year. In seconds that is 259.2 per month and 3,153.6 per year. Per day the allowance is 8.64 seconds, which is short enough that most teams tracking four nines measure in seconds rather than minutes.
Last updated August 2026
Keep reading
Where to go from here
To run the same arithmetic on any other target, use the uptime and SLA calculator, which also works backwards from the minutes you were actually down. If you are still choosing a number to commit to, what counts as a good uptime percentage compares the levels by what they cost rather than by how they look on a pricing page. For the tooling side, the uptime monitoring tools comparison rates thirteen tools by check interval and regions, which is the specification that decides whether four nines is measurable, and the uptime monitoring pricing comparison shows what each of them charges. Teams whose availability promise is customer-facing usually publish it too, which is covered in status page software. If the promise is on an API rather than a website, start with API monitoring tools and the API response time benchmarks, since an endpoint answering in 25 seconds is technically inside your uptime figure and outside your customers' patience.
259 seconds a month is not something you estimate
Uptimehub checks your sites, APIs and services every 30 seconds from six global regions, confirms a failure from a second region before it alerts you, and keeps 90 days of uptime history you can put in front of a customer. From $9 a month, priced per monitor and never per seat.