"99.9% uptime" is one of the most copy-pasted numbers on the internet. Few teams stop to convert it into real minutes per month, real hours per year, or - much worse - real seconds of error budget left after a bad Tuesday.
This guide is the calculator. Every uptime tier from 99% to 99.999% ("five nines"), expressed in seconds, minutes, hours and days, across every meaningful window: per day, per week, per month, per quarter, per year. Use it to size an SLA, set a service level objective (SLO), explain availability to a customer, or sanity-check what an outage just cost you in error budget.
If you want the conceptual version with the 99.9% vs 99.99% trade-off discussion, see Uptime SLA Explained. This page is the numbers.
How the Math Works
Allowed downtime is the simple complement of uptime:
allowed_downtime = (1 - uptime_percentage) × window_length
For 99.9% uptime over 30 days:
(1 - 0.999) × 30 × 24 × 60 × 60 = 2,592 seconds = 43.2 minutes
For 99.99% over 365 days:
(1 - 0.9999) × 365 × 24 × 60 × 60 = 3,155.76 seconds ≈ 52.6 minutes
The trick is consistency: most public SLAs are quoted per month (which favors the provider — a single 1-hour outage uses your whole 99.9% monthly budget), while engineering teams more often track SLOs per quarter or per 30-day rolling window.
Pick one window, write it down, and stop arguing about it after the incident.
The Master Table — Downtime By Uptime Tier
Numbers are rounded to two decimals where useful. Day windows use 24h, month windows use 30 days, quarter is 90 days, year is 365 days.
| Uptime | Per Day | Per Week | Per Month (30d) | Per Quarter (90d) | Per Year (365d) |
|---|---|---|---|---|---|
| 99% (two nines) | 14m 24s | 1h 40m 48s | 7h 12m | 21h 36m | 3d 15h 36m |
| 99.5% | 7m 12s | 50m 24s | 3h 36m | 10h 48m | 1d 19h 48m |
| 99.8% | 2m 52.8s | 20m 9.6s | 1h 26m 24s | 4h 19m 12s | 17h 31m 12s |
| 99.9% (three nines) | 1m 26.4s | 10m 4.8s | 43m 12s | 2h 9m 36s | 8h 45m 36s |
| 99.95% | 43.2s | 5m 2.4s | 21m 36s | 1h 4m 48s | 4h 22m 48s |
| 99.99% (four nines) | 8.64s | 1m 0.5s | 4m 19.2s | 12m 57.6s | 52m 33.6s |
| 99.995% | 4.32s | 30.24s | 2m 9.6s | 6m 28.8s | 26m 16.8s |
| 99.999% (five nines) | 0.86s | 6.05s | 25.92s | 1m 17.76s | 5m 15.36s |
Two takeaways most teams miss:
- The jump from 99.9% to 99.99% removes 7h 53m of yearly downtime. That is one big production incident.
- The jump from 99.99% to 99.999% removes 47 more minutes per year. To get there reliably you need automatic failover, multi-region traffic management, and zero-downtime deploys.
Need to put a dollar figure on this? See the Website Downtime Cost Calculator.
Three Nines, Four Nines, Five Nines — In One Line Each
| Term | Meaning | Annual downtime |
|---|---|---|
| Two nines (99%) | "We will be up most of the time." | 3 days 15 hours |
| Three nines (99.9%) | Common SaaS default. | 8 hours 45 minutes |
| Four nines (99.99%) | Enterprise tier; needs multi-AZ + careful deploys. | 52 minutes |
| Five nines (99.999%) | Telecom / payment-rail tier. | 5 minutes |
| Six nines (99.9999%) | Marketing copy; rarely measurable. | 31 seconds |
People use these terms loosely. When buying a service or signing an SLA, always require the specific percentage, the measurement window, and the definition of "downtime".
Common SLA Tiers In The Wild
Real-world examples of where each tier shows up:
| Tier | Example services |
|---|---|
| 99.5% | Free or starter SaaS plans, smaller hosting providers |
| 99.9% | Standard SaaS, most CDNs (single region), default cloud compute |
| 99.95% | Premium cloud databases (single region), most managed Kubernetes control planes |
| 99.99% | Multi-AZ cloud databases, premium CDNs, payment APIs |
| 99.999% | Telecom switches, mainframe systems, top-tier financial infrastructure |
For agencies running many client sites, see Website Monitoring for Agencies. For multi-tenant SaaS where every customer cares about their own uptime, see Multi-Tenant SaaS Monitoring.
Calculator: Allowed Downtime For Any Uptime %
For a custom tier or non-standard window, calculate it directly:
allowed_downtime_seconds = (1 - uptime_fraction) × window_seconds
window_seconds:
per minute = 60
per hour = 3,600
per day = 86,400
per week = 604,800
per 30 days = 2,592,000
per 90 days = 7,776,000
per 365 days = 31,536,000
Examples
99.97% per 30 days:
(1 - 0.9997) × 2,592,000 = 777.6 seconds = 12m 57.6s
99.92% per quarter (90 days):
(1 - 0.9992) × 7,776,000 = 6,220.8 seconds = 1h 43m 40.8s
99.85% per year (365 days):
(1 - 0.9985) × 31,536,000 = 47,304 seconds = 13h 8m 24s
Bookmark the formula. Convert into your monitoring tool's window.
Downtime Per Year At Every Common Tier
A flat list to copy-paste into proposals and runbooks:
| Uptime | Annual downtime |
|---|---|
| 95% | 18 days 6 hours |
| 98% | 7 days 7 hours 12 minutes |
| 99% | 3 days 15 hours 36 minutes |
| 99.5% | 1 day 19 hours 48 minutes |
| 99.7% | 1 day 2 hours 17 minutes 24 seconds |
| 99.8% | 17 hours 31 minutes 12 seconds |
| 99.9% | 8 hours 45 minutes 36 seconds |
| 99.95% | 4 hours 22 minutes 48 seconds |
| 99.97% | 2 hours 37 minutes 40.8 seconds |
| 99.99% | 52 minutes 33.6 seconds |
| 99.995% | 26 minutes 16.8 seconds |
| 99.999% | 5 minutes 15.36 seconds |
For a primer on why "99%" alone is often not enough, see Calculate Website Uptime — Why 99% Isn't Enough.
Monthly Downtime Budgets You Can Actually Use
Most pager rotations, post-mortems and dashboards live on a 30-day window. So this is the most useful table to print out:
| Uptime | Allowed downtime per 30 days |
|---|---|
| 99% | 7 hours 12 minutes |
| 99.5% | 3 hours 36 minutes |
| 99.8% | 1 hour 26 minutes 24 seconds |
| 99.9% | 43 minutes 12 seconds |
| 99.95% | 21 minutes 36 seconds |
| 99.99% | 4 minutes 19.2 seconds |
| 99.995% | 2 minutes 9.6 seconds |
| 99.999% | 25.92 seconds |
This is the table that turns "99.99%" into "you have four minutes a month, total, including deploys, before customers can fairly ask for credit."
How Downtime Adds Up Across Dependencies
Most production stacks chain dependencies in series: site → CDN → load balancer → app → database → identity provider → payments. The combined availability is the product of each link's availability:
combined = a1 × a2 × a3 × ... × an
Five components each at 99.9%:
0.999^5 = 0.99501 ≈ 99.5%
That is 3h 36m of downtime per 30 days even though each individual component "meets its SLA." This is one of the biggest reasons real-world uptime is worse than the sum of component SLAs.
For the third-party angle - what to do about pieces you don't control - see Third-Party Dependency Monitoring. For payments specifically, see Stripe Payment Monitoring.
Error Budgets: Downtime As A Spending Account
Treat allowed downtime as a budget you can spend or save:
- Budget remaining = allowed downtime − downtime used this window.
- Burn rate = downtime used per hour, compared to allowed downtime per hour.
- Reset cadence = the window (e.g. rolling 30 days).
A common policy: if you burn 50% of the monthly budget in 7 days, freeze risky deploys until burn rate normalises. See SLO Monitoring & Error Budgets for the full pattern.
What Counts As "Downtime"?
The numbers above are useless without a definition. Spell it out:
- HTTP 5xx for more than X consecutive minutes?
- p95 response time over Y ms?
- Specific user journey (login, checkout, dashboard) failing from multiple regions?
- A maintenance window — does it count or not?
- Partial degradation — is "checkout broken, marketing site up" downtime?
A formal definition usually looks like:
"Downtime occurs when more than 1% of requests over a 5-minute rolling window return a 5xx response or a response time greater than 5 seconds, as observed from at least 2 external monitoring locations."
Without that level of precision, every outage becomes an argument. For the per-component view, see HTTP Status Codes Explained and 5xx Error Rate Monitoring.
Picking The Right Tier
Use this as a starting point, then justify any deviation:
| Audience | Suggested target | Why |
|---|---|---|
| Internal tools | 99% | Engineering time is more valuable than nines |
| Marketing site | 99.9% | Outages affect leads and SEO |
| B2B SaaS | 99.9% - 99.95% | Matches typical customer expectations |
| Mission-critical SaaS | 99.99% | Customers run their business on you |
| Payment / health / safety | 99.999% | Failure has real-world consequences |
Higher tiers cost more in infrastructure, more in headcount, and more in culture (changes get slower). Match the SLA to the actual cost of downtime, not to a number that sounds good in a sales deck.
For peak-traffic decisions (Black Friday, product launches), see Peak Traffic Monitoring.
How To Measure It
You cannot manage what you do not measure. To actually report against any of these numbers, you need:
- External multi-region uptime checks at 1-minute intervals so brief outages are recorded accurately. See 1-minute vs 5-minute monitoring.
- Synthetic checks for the user-visible journeys, not just the homepage. See Synthetic vs Real User Monitoring.
- Status page entries that match what was monitored - no quiet "we updated the report after the fact" edits.
- Definition-aware reporting that excludes scheduled maintenance only when contractually allowed. See Scheduled Maintenance Windows.
- Multi-region awareness so a single region's view does not skew the report. See Multi-Region Monitoring.
Uptime Calculator Checklist
- SLA percentage decided and documented
- Measurement window defined (per 30 days vs per year)
- Downtime definition documented (status codes, latency, scope)
- Maintenance window policy documented
- Allowed downtime calculated for each window
- Error budget reset cadence agreed
- Burn-rate alerts configured
- External multi-region checks running at 1-minute interval
- Status page and SLA report sourced from the same data
- Annual review of tier, since cost-of-downtime changes
How Webalert Helps
Webalert is built to measure against these exact numbers:
- External 1-minute checks from multiple regions so brief outages show up in the math.
- SLA-aware reporting that converts raw downtime into your target tier's budget.
- Multi-region awareness so single-region blips do not silently consume your budget.
- Content validation so "200 OK with wrong content" still counts as down. See Response Body Validation Monitoring.
- Status page sourced from the monitor itself - no retroactive editing.
- Alert routing that pages humans when burn rate exceeds the threshold you set.
Example Webalert SLA check:
- URL:
https://example.com/health - Frequency: every 60 seconds
- Regions: US, EU, APAC
- Pass condition: HTTP 200 + body contains
"status":"ok"+ response time < 1500ms - SLA target: 99.95% over a rolling 30-day window
- Alert: page when 50% of monthly budget burned in any 6-hour window
Summary
Uptime percentages are easy to quote and harder to honor. Three nines is 43 minutes of allowed downtime per month. Four nines is four minutes. Five nines is twenty-five seconds.
Pick the tier the business needs, write the definition down, measure it externally, and treat allowed downtime as a budget you spend on deploys, incidents and dependencies. The math is the easy part - the harder part is making the SLA mean the same thing on a customer call as it does in your dashboards.