99.95% Uptime: What a 99.95% Uptime SLA Means in Minutes per Month and Hours per Year
99.95% is the step-up tier: half the downtime of 99.9%, five times more than 99.99%. Here is the exact allowance for every period, which clouds publish it, and what it takes to hold.
Which SLA tier did the month meet?
LiveUptime achieved: 99.9722%
99.95% is 0.05% of the period, which is 1,296 seconds on a 30 day month. Try 12 minutes: it clears 99.9% and 99.95% comfortably, and it is nearly three times the entire 99.99% budget.
In short
99.95% uptime allows 21 minutes 36 seconds of downtime in a 30 day month and 4 hours 22 minutes 48 seconds across a full year. Per day that is 43 seconds. It is exactly half the allowance of 99.9% and five times more generous than 99.99%, which is why it has become the standard step-up tier: Azure commits to 99.95% for virtual machines in an availability set, and Google commits to 99.95% for Cloud SQL Enterprise edition with high availability. Unlike four nines, it is reachable without fully automated multi-region failover.
Exact figures
How much downtime 99.95% uptime allows, per period
Every figure below is the length of the period multiplied by 0.0005. 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 over two minutes.
| Period | Downtime allowed at 99.95% | What that is in practice |
|---|---|---|
| Per hour | 1.8 seconds | Below the resolution of most monitoring |
| Per day | 43 seconds | One rolling deploy that stalls briefly |
| Per week | 5 minutes 2 seconds | A single unplanned database failover |
| Per 28 day month | 20 minutes 10 seconds | February, the tightest month you get measured on |
| Per 30 day month | 21 minutes 36 seconds | The convention most SaaS contracts use |
| Per 31 day month | 22 minutes 19 seconds | The most generous calendar month |
| Per calendar-average month | 21 minutes 54 seconds | A 365 day year divided by twelve |
| Per quarter | 1 hour 5 minutes 42 seconds | Two moderate incidents, or one bad one |
| Per year | 4 hours 22 minutes 48 seconds | Half a working day, spread across twelve months |
Twenty-one minutes and thirty-six seconds is a genuinely useful amount of time, and that is the whole reason this tier exists. It is long enough for somebody to be paged, open a laptop, read a dashboard and trigger a failover. Four nines is not, which is why the two levels feel so different to operate despite being one decimal place apart on paper.
The annual figure is the one worth quoting internally. Four hours and twenty-three minutes across a whole year sounds generous until you notice it is a single long afternoon. One badly handled database migration can spend the entire year in one sitting. For the same arithmetic at any other target, the uptime calculator runs it in both directions from 90% to 99.9999%.
Verified commitments
Which cloud providers actually commit to 99.95% uptime
Every figure in this table was read from the vendor's own SLA or documentation in August 2026. The pattern worth noticing is that 99.95% is almost always the single-zone version of a service whose multi-zone version is sold at 99.99%.
| Provider | Service and configuration | Committed uptime | What sits either side of it |
|---|---|---|---|
| Microsoft Azure | Virtual machines, two or more instances in one availability set | 99.95% | Availability zones instead of an availability set raise the same commitment to 99.99% |
| Google Cloud | Cloud SQL Enterprise edition with high availability | 99.95% | Cloud SQL Enterprise Plus with HA commits to 99.99%, so the nine is a paid product tier |
| Google Cloud | Cloud SQL, single-zone or shared-core instances | Not covered | Excluded from the SLA entirely, not given a lower number |
| Amazon Web Services | EC2 instance-level, a single instance | 99.5% | Well below 99.95%, and the figure most people are surprised by |
| Amazon Web Services | EC2 region-level, deployed across multiple availability zones | 99.99% | AWS publishes no 99.95% tier for EC2, it steps from 99.5% straight to 99.99% |
Two things fall out of that table. The first is that the nine you get is a function of your deployment topology, not of the product you bought. The same Azure virtual machines are covered at 99.95% in an availability set and 99.99% across availability zones, and the same Cloud SQL engine is covered at 99.95% on Enterprise edition and 99.99% on Enterprise Plus. You are buying the redundancy, and the percentage is the label on it.
The second is that a configuration can fall outside the SLA entirely. Google does not give single-zone or shared-core Cloud SQL instances a lower number, it excludes them from the agreement. AWS is blunter still: EC2 commits to 99.5% for one instance, which permits three hours thirty-six minutes of downtime a month, and only reaches 99.99% once you are spread across availability zones. Check the topology clause before you quote any of these numbers to a customer.
What a breach pays
What you actually get back when a 99.95% SLA is missed
These are Google Cloud's published credit tiers for Cloud SQL Enterprise edition, which is a fair representative of how 99.95% remedies are usually written. Credits must be claimed within thirty days of becoming eligible.
| Monthly uptime achieved | Financial credit | Roughly what that month looked like |
|---|---|---|
| 99.0% to below 99.95% | 10% of the monthly bill | You were down between 21 minutes and 7 hours 12 minutes |
| 95.0% to below 99.0% | 25% of the monthly bill | You were down between 7 hours and 1 day 12 hours |
| Below 95.0% | 50% of the monthly bill | You were down more than a day and a half in the month |
Run the arithmetic on your own bill before treating this as protection. A managed database costing $2,000 a month that spends six hours down returns $200. Nobody who has just lost six hours of trading considers that a remedy. The credit schedule is worth reading for a different reason: it tells you how confident the vendor is, and how far things have to go wrong before they are willing to pay anything at all.
In context
99.9% vs 99.95% vs 99.99% uptime
Uptime levels are usually described as nines, which hides the fact that 99.95% is a half step rather than a full one. 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 | 26s | 5m 15s | Telecoms, payments, emergency systems |
The two steps around 99.95% are not the same size, and that is the most useful thing on this page if you are deciding what to promise. Moving up from 99.9% halves the budget, and teams usually get there by detecting failures faster and rehearsing the failover rather than by buying anything. Moving up to 99.99% uptime divides the budget by five and puts it below the time a human needs to respond at all, so it has to be bought with architecture.
That is why so many pricing pages stop at 99.95%. It is the highest number a vendor can commit to while still recovering with people rather than with automation. 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 the practice of spending the allowance deliberately instead of discovering it is gone.
Measurement
What check interval you need to verify 99.95% uptime
A monitor cannot record an outage shorter than the gap between its checks. At 99.95% the monthly budget is 1,296 seconds, so unlike four nines this level is genuinely measurable with ordinary tooling, provided the interval is a minute or better.
| Check interval | Shortest outage it can record | Monthly 99.95% budget spent by one detection | Good enough for 99.95%? |
|---|---|---|---|
| Every 5 minutes | 5 minutes | 23% | Only four detections before the month is gone. Too coarse to manage |
| Every 3 minutes | 3 minutes | 14% | Workable for reporting, still blind to short outages |
| Every 60 seconds | 60 seconds | 4.6% | Yes. Twenty-one detections fit inside the budget |
| Every 30 seconds | 30 seconds | 2.3% | Yes, with margin for a false positive or two |
| Every 15 seconds | 15 seconds | 1.2% | More resolution than 99.95% needs |
This is the practical dividing line between the two tiers. At 99.99% a five minute check is arithmetically useless, because one detection already exceeds the entire monthly budget. At 99.95% the same check burns 23% of the month, which is bad but not meaningless. Sixty seconds is the point where the measurement stops distorting the result, and thirty seconds gives you room for the occasional false positive without it costing you the month.
Confirmation matters as much as frequency. A single probe having a bad thirty seconds is common on the public internet, and an unconfirmed false positive is 2.3% of your budget recorded as an outage that never happened. Requiring a second region to agree before an incident counts is what turns a noisy percentage into one you can put in front of a customer, which is covered on multi-location monitoring. The reporting side, including keeping the history that a contract dispute needs, is on SLA monitoring.
Measure it
Check what your service is doing right now
A 99.95% commitment 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 if you want the number tracked with enough resolution to defend.
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 takes to actually hold 99.95% uptime
None of this is exotic, and that is the point. 99.95% is the highest tier most teams can reach with disciplined operations rather than a redesign.
Redundancy where the failure is likely, not everywhere
This is the practical difference from four nines. At 99.95% you need the database, the load balancer and the application tier to survive a single node loss, but you do not need every layer duplicated across regions. Two instances in one availability set is exactly the shape Azure prices its 99.95% commitment around.
Failover that completes inside about twenty minutes
Twenty-one minutes and thirty-six seconds a month is enough time for a human to be paged, look at a dashboard and trigger a failover, provided the runbook exists and somebody is genuinely on call. That is the single biggest reason 99.95% costs so much less than 99.99%: it does not require the recovery to be automatic.
Deploys that fail closed and roll back
A release that drops connections for forty seconds spends 3% of the month. Do that weekly and you have spent 12% before a real incident. Rolling deploys with health checks are enough here. You do not need blue-green with automatic error-rate rollback, which is what the next nine up demands.
A maintenance window you have actually negotiated
Most 99.95% contracts exclude announced maintenance. If yours does not, a single two hour patching window has spent more than five months of budget in one night. Decide this before signing, because it changes the number from a stretch target to an impossible one.
Monitoring at 60 seconds or better, from more than one region
The budget is 1,296 seconds a month. A monitor checking every five minutes burns 23% of it on one detection and cannot see anything shorter, so its reported percentage is not precise enough to defend. Sixty second checks with a second region confirming the failure is the minimum specification that makes a 99.95% figure arguable.
Dependencies that individually beat 99.95%
Availability multiplies downward. A stack on a 99.99% host, a 99.99% CDN and a 99.95% managed database has a ceiling near 99.93%, which is already under the number before your own code runs. Either every dependency in the critical path clears 99.95%, or you need a path that routes around the weakest one.
The dependency arithmetic in the last point catches more teams than any of the others. Availability multiplies rather than averages, so a critical path made of components at 99.99%, 99.99% and 99.95% has a mathematical ceiling around 99.93% before your own application has run a line of code. If you intend to publish 99.95%, everything in that path has to clear it individually, or you need a design that keeps the weakest component off the path when it fails.
Read the contract
What a 99.95% uptime SLA quietly leaves out
The arithmetic on this page is exact. What a contract chooses to measure is a negotiation, and that is where 99.95% disputes actually happen.
Half of 99.9% costs far less than a fifth of it
Going from 99.9% to 99.95% halves the allowance, from 43 minutes 12 seconds a month to 21 minutes 36 seconds. Going from 99.95% to 99.99% divides it by five, down to 4 minutes 19 seconds. The first step is usually monitoring, a rehearsed runbook and a real on-call rota. The second step is an architecture change. That asymmetry is why 99.95% is where so many paid tiers stop.
Exclusions can be worth more than the commitment
Read what is carved out before you read the percentage. Google excludes single-zone and shared-core Cloud SQL instances from its SLA completely rather than giving them a lower number, and excludes scheduled maintenance from the Enterprise edition calculation. A 99.95% number that does not cover your deployment topology is not a 99.95% number at all.
Service credits are a signal, not a remedy
Google Cloud pays 10% of the monthly bill for a month between 99.0% and 99.95%, and you have to claim it within thirty days. On a $2,000 database bill, a month with six hours of downtime returns $200. Treat published credits as a statement of engineering confidence rather than as compensation, because they will never cover what an outage actually costs you.
Partial failure is usually recorded as available
Availability is normally measured as one request to one endpoint returning a success code. Slow responses, one broken API route or a checkout that fails for a single card processor will all be logged as uptime. If your 99.95% is commercially meaningful, define it on the transaction that earns money rather than on whether the homepage answers.
The measurement window decides the difficulty
A monthly 99.95% gives you 21 minutes 36 seconds that cannot be carried over. An annual 99.95% gives you 4 hours 22 minutes and lets one bad afternoon in March be absorbed by eleven clean months. The percentages look identical in a contract. The monthly version is meaningfully harder to hold.
If you are buying rather than selling, ask two questions before anything else: what the measurement window is, and what the exclusions clause removes. A 99.95% annual SLA with maintenance excluded is a weaker promise than a 99.9% monthly SLA measured on everything, even though the headline number looks twice as good. Holding a vendor to whichever definition you agreed on takes independent measurement, which is what SLA monitoring is for, and what a status page makes visible to your own customers in the other direction.
FAQ
Questions people ask about 99.95% uptime
99.95% uptime means a service may be unavailable for 0.05% of the measured period. In a 30 day month that is 21 minutes 36 seconds, and across a 365 day year it is 4 hours 22 minutes 48 seconds. It is the tier most commonly used for paid business plans and managed cloud databases, sitting between the 99.9% default and enterprise 99.99%.
It means 21 minutes 36 seconds of downtime in a 30 day month, 21 minutes 54 seconds if the month is defined as a 365 day year divided by twelve, and 4 hours 22 minutes 48 seconds over a full year. Per day the allowance is 43 seconds and per week it is 5 minutes 2 seconds.
99.95% uptime allows 4.38 hours of downtime per year, which is 4 hours 22 minutes 48 seconds. Per 30 day month it is 0.36 hours, or 21 minutes 36 seconds. Expressed the other way round, a 99.95% service must be available for 8,755.62 hours out of the 8,760 hours in a year.
On a 30 day month, 21 minutes 36 seconds. On a 31 day month, 22 minutes 19 seconds. On February with 28 days, 20 minutes 10 seconds. Contracts defining a month as a 365 day year divided by twelve give 21 minutes 54 seconds. The spread between the shortest and longest month is over two minutes, which is roughly a tenth of the whole budget.
Exactly a factor of two. 99.9% allows 43 minutes 12 seconds a month and 8 hours 46 minutes a year, while 99.95% allows 21 minutes 36 seconds a month and 4 hours 23 minutes a year. Operationally the gap is small: the same architecture usually reaches both, and what closes it is faster detection and a rehearsed failover rather than new infrastructure.
A factor of five. 99.95% permits 21 minutes 36 seconds a month, 99.99% permits 4 minutes 19 seconds. That gap cannot be closed by responding faster, because no human can be paged, diagnose a fault and restore service inside four minutes. Moving from 99.95% to 99.99% means automated failover and multi-zone redundancy, which is why vendors charge for it as a separate product tier.
Yes, for most paid software it is the right target. It is twice as strict as the 99.9% that many vendors publish by default, it is defensible with an on-call rota rather than automated failover, and it is what Azure commits to for virtual machines in an availability set. Go higher only when a few minutes of unavailability carries a direct revenue or contractual cost.
Multiply the period length by 0.0005. A 30 day month is 2,592,000 seconds, so the allowance is 1,296 seconds, which is 21 minutes 36 seconds. A 365 day year is 31,536,000 seconds, giving 15,768 seconds, or 4 hours 22 minutes 48 seconds. To check a month you already ran, take total minutes minus downtime minutes, divide by total minutes, then multiply by 100.
Microsoft Azure commits to 99.95% for virtual machines with two or more instances in the same availability set, and Google Cloud commits to 99.95% for Cloud SQL Enterprise edition with high availability. Both raise the figure to 99.99% for the multi-zone version of the same service. AWS publishes no 99.95% tier for EC2: it goes from 99.5% at the instance level to 99.99% at the region level.
Typically 10% of the monthly bill for the first band. Google Cloud pays 10% for a Cloud SQL Enterprise month between 99.0% and 99.95%, 25% between 95.0% and 99.0%, and 50% below 95.0%, claimable within thirty days. Credits are capped at a fraction of one month of spend, so they rarely approach the commercial cost of the outage.
21.6 minutes per 30 day month and 262.8 minutes per year. In seconds that is 1,296 a month and 15,768 a year. A single 30 minute incident spends 139% of the monthly budget, so one bad afternoon breaks the month outright even if nothing else goes wrong.
Yes, provided it checks at least every 60 seconds. At that interval one detected failure consumes 4.6% of the monthly budget, so around twenty-one detections fit inside 99.95%. A five minute check burns 23% per detection and cannot record anything shorter than five minutes, which makes its percentage too coarse to defend in a contract dispute.
Last updated August 2026
Keep reading
Where to go from here
The level above this one is covered in full on 99.99% uptime, including why four nines cannot be verified by a five minute monitor, and the level below on what 99.9% uptime means, which is still where most SaaS products sit. To run the arithmetic on any target at all, including backwards from the minutes you were actually 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, which is the specification that decides whether a 99.95% figure is defensible, and the uptime monitoring pricing comparison shows what each of them charges. If the commitment is 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 and will still lose you the customer.
1,296 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.