How much downtime does 99.9% uptime allow?

99.9% uptime allows 8 hours and 46 minutes of downtime per year, 43 minutes and 50 seconds per month, 10 minutes and 5 seconds per week, and 1 minute and 26 seconds per day. A single 20-minute incident can consume two months of your annual budget at this tier.

What does five nines uptime mean?

Five nines means 99.999% uptime. It allows 5 minutes and 15 seconds of downtime per year. Achieving five nines requires active-active multi-region deployments, automated failover in under 60 seconds, and incident response times measured in seconds, not minutes.

How do I calculate uptime percentage from downtime?

Uptime % = (total minutes in period - downtime minutes) / total minutes in period × 100. A month has 43,800 minutes (30.4 days × 24 hours × 60 minutes). If you had 20 minutes of downtime in a month, your uptime was (43,800 - 20) / 43,800 × 100 = 99.954%.

Does scheduled maintenance count against uptime?

It depends on your SLA. Many vendor SLAs exclude scheduled maintenance from uptime calculations. A provider can schedule 4 hours of maintenance every month and still claim 99.99% uptime for the remaining time. Always read the SLA's measurement methodology section, not just the headline percentage.

What uptime tier do most SaaS products achieve?

Most SaaS products target 99.9% and achieve between 99.5% and 99.95% in practice. Reaching 99.99% requires architectural investment in multi-region deployments, circuit breakers, and automated failover that most early-stage products cannot justify financially.

What is error budget?

Error budget is the inverse of your uptime target. If your SLO is 99.9% uptime, your error budget is 0.1% of total time: 8.77 hours per year. When you consume your error budget, you stop shipping features and focus on reliability until the budget recovers.

Uptime Availability Table: What 95% to 99.999% Uptime Means in Real Downtime

Uptime percentage measures the proportion of time a system stays operational. Every decimal place you add to that number means 90% less allowable downtime than the tier before it.

Uptime percentage expresses availability as a ratio of operational time to total time. 99.9% uptime means your service can be down for 0.1% of time. In a 365-day year, 0.1% equals 8 hours and 46 minutes. That sounds like a lot. One slow incident response can consume it entirely.

The jump from 99% to 99.9% sounds small. The operational difference is 3.65 days of allowed downtime versus 8.77 hours. Each nine you add to the end of that number changes what your architecture, incident response process, and monitoring setup must look like.

The complete uptime availability table

All figures use a 365.25-day year (8,766 hours) and a 30.44-day month (730.6 hours).

Uptime	Downtime/Year	Downtime/Month	Downtime/Week	Downtime/Day
95.0%	18 days 6 hrs	36 hrs 32 min	8 hrs 24 min	1 hr 12 min
96.0%	14 days 14 hrs	29 hrs 13 min	6 hrs 43 min	57 min 36 sec
97.0%	10 days 22 hrs	21 hrs 55 min	5 hrs 2 min	43 min 12 sec
98.0%	7 days 7 hrs	14 hrs 36 min	3 hrs 21 min	28 min 48 sec
99.0%	3 days 15 hrs	7 hrs 18 min	1 hr 41 min	14 min 24 sec
99.5%	1 day 19 hrs	3 hrs 39 min	50 min 24 sec	7 min 12 sec
99.9%	8 hrs 46 min	43 min 50 sec	10 min 5 sec	1 min 26 sec
99.95%	4 hrs 23 min	21 min 55 sec	5 min 2 sec	43 sec
99.99%	52 min 36 sec	4 min 22 sec	1 min 1 sec	8.6 sec
99.999%	5 min 16 sec	26.3 sec	6.1 sec	0.86 sec

What each tier actually means

95%–98%: Pre-production or internal tools only

A 95% SLA allows 18 days of downtime per year. That is appropriate for dev environments, internal tooling, or staging infrastructure where occasional unavailability is acceptable. No customer-facing production service should target below 99%.

96%–98% still allows multiple hours of downtime per month. Development portals, internal analytics dashboards, and non-critical admin tools sometimes operate at these tiers.

99%: The floor for production

99% uptime allows 3.65 days of downtime per year or about 7 hours per month. Most bare-minimum SaaS products and hobby projects operate in this range. At 99%, you can survive a single major incident per month without breaching your SLA.

What 99% allows architecturally: single-region deployment, nightly deployments with brief downtime windows, manual incident response during business hours.

What 99% does not tolerate: multiple incidents per month, slow incident response, or infrastructure without basic redundancy.

99.5%: The realistic minimum for SaaS

99.5% allows about 3.5 hours of downtime per month. This is achievable with a single-region deployment that has redundant app servers and a managed database with automatic failover.

Most bootstrapped SaaS products operate between 99.5% and 99.9% without explicit targeting. They hit this range through good infrastructure choices rather than formal SLA engineering.

99.9%: The standard commercial SLA

99.9% is the most common uptime commitment in commercial SaaS contracts. It allows 43 minutes and 50 seconds of downtime per month.

Most cloud infrastructure providers (AWS, GCP, Azure) publish 99.9% SLAs for their managed services. Heroku, Render, and Railway operate in this range. Your application's availability cannot exceed your infrastructure's availability, so if your hosting provider commits to 99.9%, that is your ceiling before you add multi-region redundancy.

What 99.9% requires:

Automated deployment with zero-downtime rolling updates
Managed database with automatic failover (not manual)
Load balancer across multiple application server instances
Alert response within 10 minutes around the clock
On-call rotation for incidents during off-hours

A single 20-minute incident consumes almost half your monthly budget. If your incident response takes longer than 20 minutes, you will breach 99.9% during any major outage.

99.95%: Where enterprise SaaS lives

99.95% allows 21 minutes and 55 seconds per month. This tier requires the same stack as 99.9% plus faster incident detection and response.

Getting from 99.9% to 99.95% usually comes from:

Reducing time-to-detection (better monitoring, shorter check intervals)
Reducing time-to-alert (alerting from multiple regions simultaneously, not waiting for retries)
Reducing time-to-response (better runbooks, better on-call escalation)

The architectural requirements are similar to 99.9%. The operational requirements are tighter.

99.99%: Four nines

99.99% allows 52 minutes and 36 seconds of downtime per year. A single incident that takes 45 minutes to resolve consumes 85% of your annual budget.

What 99.99% requires that 99.9% does not:

Multi-region active-active deployment: traffic splits across at least two regions; either can serve all traffic if the other fails
Automated failover: a human cannot make the "switch traffic to the healthy region" decision fast enough; it must be automated
Sub-5-minute incident detection: your monitoring needs to detect and alert within 2-3 minutes of failure onset
Sub-30-minute mean time to recovery for all incident types, including database failures
Regular failover testing: you need to test your failover mechanism regularly to know it works when you need it

Financial services, healthcare platforms, and enterprise B2B software typically target 99.99%.

99.999%: Five nines

99.999% allows 5 minutes and 16 seconds of downtime per year. This is the tier major telecommunications carriers and financial clearing systems target.

Five nines is not just an architecture problem; it is an organization problem. At this tier:

Deployments must be blue-green or canary, with automated rollback on the first error signal
Database failover must complete in under 60 seconds with zero data loss
Incident detection must fire within 30 seconds of failure
The on-call engineer must acknowledge and begin mitigation within 2 minutes
Every dependency (payment processor, email provider, DNS) must have a fallback

Most SaaS products have no business targeting five nines. The engineering cost of building and maintaining five-nines infrastructure usually exceeds the customer value it preserves.

How to calculate your actual uptime

Use this formula:

Uptime % = ((total_minutes - downtime_minutes) / total_minutes) × 100

For a 30-day month:

Total minutes: 30 × 24 × 60 = 43,200 minutes
If you had 25 minutes of downtime: (43,200 - 25) / 43,200 × 100 = 99.942%

For a 31-day month:

Total minutes: 31 × 24 × 60 = 44,640 minutes
If you had 25 minutes of downtime: (44,640 - 25) / 44,640 × 100 = 99.944%

Month length affects your SLA math. February gives you the smallest denominator, which means the same downtime duration produces a lower uptime percentage in February than in March.

Read how to calculate uptime: the complete guide for the full calculation methodology, including weighted uptime across multiple services.

Error budget: the practical way to use uptime targets

Error budget flips the uptime percentage into an operational tool. If your uptime target is 99.9%, your error budget is 0.1% of time per month: 43 minutes and 50 seconds.

Every minute of downtime burns from that budget. When the budget is full, you can ship features freely. When the budget is 50% consumed halfway through the month, you slow feature releases and focus on stability. When the budget is gone, deployments pause until the next period.

Error budget gives product and engineering a shared language for the reliability vs. velocity trade-off. It removes the subjective argument about whether it is safe to ship and replaces it with a measurable constraint.

Google's SRE book introduced error budget as a formal concept. The approach works for any team that commits to an explicit uptime target.

Maintenance windows and SLA math

Most vendor SLAs exclude scheduled maintenance from uptime calculations. This is worth reading carefully.

A provider who can schedule unlimited maintenance windows can exclude those hours from the uptime denominator. Their uptime calculation runs on the reduced total time, making it easier to hit 99.99% even with significant planned downtime.

When negotiating SLAs, ask:

Does scheduled maintenance count against uptime?
What is the maximum maintenance window duration per month?
How much notice is required before a maintenance window?

If maintenance is excluded, ask for explicit limits on frequency and duration. "Unlimited scheduled maintenance excluded" is a loophole large enough to eliminate the SLA commitment entirely.

Monitoring your uptime to know your actual tier

The only way to know your actual uptime percentage is to measure it continuously with independent monitoring.

Your hosting provider's status page reflects incidents they acknowledge. External monitoring reflects incidents your users experience. The two numbers are almost never identical.

Vantaj runs checks every 30-60 seconds from up to 10 global regions. Your dashboard shows your current-period uptime percentage in real time. Your historical data shows month-by-month availability going back as far as your account. When you need to validate an SLA credit claim, you export the check history as evidence.

For how to set up monitoring that generates this data accurately, read the uptime monitoring guide and SLA uptime monitoring: how to track your commitments.

For the contractual context around these numbers, read what is an SLA and SLA vs SLO vs SLI.