Uptime Calculator: Convert Percentages to Actual Downtime

The Math Behind Uptime Percentages

Uptime is expressed as a percentage of total time. The formula is simple:

Uptime % = ((Total Time - Downtime) / Total Time) x 100

To go the other direction and find the allowed downtime for a given uptime percentage:

Allowed Downtime = Total Time x (1 - Uptime % / 100)

For example, 99.9% uptime over a 30-day month:

• Total minutes in 30 days: 30 x 24 x 60 = 43,200
• Allowed downtime: 43,200 x (1 - 0.999) = 43,200 x 0.001 = 43.2 minutes

That is the entire budget. Every minute of downtime during the month counts against it. For a deeper look at the formula and worked examples, see how to calculate uptime.

Uptime Conversion Table

This table shows the maximum allowed downtime for common uptime percentages across different time periods.

Per Year (365 days)

| Uptime % | Downtime Per Year | |----------|------------------| | 99% (two nines) | 3 days, 15 hours, 36 minutes | | 99.5% | 1 day, 19 hours, 48 minutes | | 99.9% (three nines) | 8 hours, 45 minutes, 36 seconds | | 99.95% | 4 hours, 22 minutes, 48 seconds | | 99.99% (four nines) | 52 minutes, 33.6 seconds | | 99.999% (five nines) | 5 minutes, 15.4 seconds | | 99.9999% (six nines) | 31.5 seconds |

Per Month (30 days)

| Uptime % | Downtime Per Month | |----------|-------------------| | 99% | 7 hours, 12 minutes | | 99.5% | 3 hours, 36 minutes | | 99.9% | 43 minutes, 12 seconds | | 99.95% | 21 minutes, 36 seconds | | 99.99% | 4 minutes, 19 seconds | | 99.999% | 25.9 seconds |

Per Week (7 days)

| Uptime % | Downtime Per Week | |----------|------------------| | 99% | 1 hour, 40 minutes, 48 seconds | | 99.5% | 50 minutes, 24 seconds | | 99.9% | 10 minutes, 4.8 seconds | | 99.95% | 5 minutes, 2.4 seconds | | 99.99% | 1 minute, 0.5 seconds | | 99.999% | 6 seconds |

Why the Gap Between 99.9% and 99.99% Is Enormous

At first glance, 99.9% and 99.99% look almost identical. They differ by just 0.09 percentage points. But in terms of allowed downtime, the gap is massive.

99.9% uptime allows roughly 8 hours and 46 minutes of downtime per year. 99.99% allows roughly 52 minutes and 34 seconds. That is a 10x reduction. Going from three nines to four nines means your total annual downtime budget drops from "a bad morning" to "less than a lunch break."

Each additional nine is 10x harder than the last. This is why the nines of uptime are such a common reference point in SLA discussions. The difficulty and cost of maintaining each level increases exponentially, not linearly.

• 99% to 99.9%: Requires automated monitoring, basic redundancy, and reasonable infrastructure. Most competent hosting setups can achieve this.
• 99.9% to 99.99%: Requires redundant infrastructure, automated failover, comprehensive monitoring, and well-practiced incident response. This is where significant engineering investment begins.
• 99.99% to 99.999%: Requires multi-region deployment, zero-downtime deployments, extensive automation, and near-instant failover. Only critical infrastructure targets this level.

How to Calculate Uptime From Incident Logs

If you have records of your past incidents, you can calculate your actual uptime.

Step 1: Choose Your Time Period

Pick a consistent period: the last 30 days, the last quarter, or the last year. Make sure you have incident data covering the entire period.

Step 2: Sum Total Downtime

Add up the duration of every incident during that period. Be specific about what counts as "downtime." A full outage is obvious. A partial outage where the homepage works but checkout is broken might count as downtime for SLA purposes, or it might not, depending on how your SLA defines availability.

Step 3: Apply the Formula

Uptime % = ((Total Minutes in Period - Total Downtime Minutes) / Total Minutes in Period) x 100

Worked example:

• Time period: January (31 days = 44,640 minutes)
• Incident 1: 23 minutes of full downtime on January 8
• Incident 2: 47 minutes of full downtime on January 19
• Incident 3: 12 minutes of full downtime on January 27
• Total downtime: 82 minutes
• Uptime: ((44,640 - 82) / 44,640) x 100 = 99.816%

That is below three nines (99.9%). If your SLA promises 99.9%, three incidents totaling 82 minutes in a 31-day month would put you in breach. The allowed downtime for 99.9% over 31 days is about 44.6 minutes.

Step 4: Compare Against Your SLA

Once you have your actual uptime percentage, compare it to what your SLA promises. If you are a service provider, this tells you whether you owe credits. If you are a customer evaluating a provider, this tells you whether they are meeting their commitments. Our uptime SLA guide covers how to read and negotiate these agreements.

SLA Breach Thresholds

Most SLAs define consequences for failing to meet the uptime target. Common structures include:

Service Credit Models

| Actual Uptime | Typical Credit | |--------------|---------------| | Below SLA target but above 99% | 10% of monthly fee | | Below 99% but above 95% | 25% of monthly fee | | Below 95% | 50% of monthly fee | | Below 90% | 100% of monthly fee |

The specific thresholds vary by provider. The important thing is to know where the lines are and to track your actual uptime against them.

What Counts as Downtime in an SLA

SLAs often exclude certain types of downtime from the calculation:

• Scheduled maintenance: Most SLAs exclude pre-announced maintenance windows from the uptime calculation
• Force majeure: Natural disasters, widespread internet outages, and other events outside the provider's control
• Customer-caused issues: Downtime resulting from the customer's own configuration or code
• Beta or preview services: Features not yet generally available

Read the fine print. A provider advertising 99.99% uptime with broad exclusions might deliver a worse actual experience than one advertising 99.9% with narrow exclusions.

Practical Implications by Business Type

Different businesses have different tolerance for downtime. The right uptime target depends on what your service does and who depends on it.

Informational Websites and Blogs

Target: 99.5% to 99.9%

A blog or marketing site that goes down for an hour causes frustration but rarely causes direct financial loss. Visitors will come back. Search engines will re-crawl. The reputational impact is minor unless downtime is frequent. The bigger risk is SEO impact from repeated outages, which we cover in the cost of website downtime.

E-commerce Stores

Target: 99.9% to 99.95%

Every minute of downtime on a store is directly measurable in lost sales. During peak traffic periods (product launches, holiday sales, marketing campaigns), the cost per minute of downtime spikes. E-commerce sites should target at least three nines and invest in redundancy for their checkout flow specifically.

SaaS Applications

Target: 99.95% to 99.99%

SaaS customers pay for access. When the application is down, customers cannot do their work and your support team gets flooded. SaaS SLAs are scrutinized by enterprise buyers, and a poor uptime track record can disqualify you from deals. Most competitive SaaS products target 99.95% or higher.

Financial Services and Healthcare

Target: 99.99% to 99.999%

Regulated industries often have compliance requirements around availability. Downtime can have legal consequences, not just business consequences. These organizations invest heavily in redundancy, failover, and disaster recovery.

Internal Tools

Target: 99% to 99.9%

Internal dashboards, admin panels, and development tools affect productivity but not revenue directly. A lower uptime target is usually acceptable, which frees up engineering resources for customer-facing services.

Common Mistakes When Using Uptime Calculations

Mixing time periods. Comparing a monthly uptime number to an annual SLA target is meaningless. A single bad month with 99.5% uptime can still result in 99.95% for the year if the other eleven months are clean. Always compare like with like.

Ignoring partial outages. If half your users cannot reach your site due to a regional DNS issue, is that 50% downtime or 100% downtime? Most simple calculations treat any failure as full downtime. For a more accurate picture, weight downtime by the percentage of users affected.

Counting only detected downtime. Your uptime is only as accurate as your monitoring. If you check your site every 5 minutes, you could miss a 4-minute outage entirely. Higher check frequency gives you more accurate uptime data. Our uptime monitoring guide covers how check frequency affects accuracy.

Treating uptime as a vanity metric. A 99.97% uptime number looks great on a status page. But if those 0.03% of downtime minutes all happened during your biggest product launch, the business impact was severe. Context matters more than the number itself.

Assuming linear difficulty. Going from 99% to 99.9% is achievable with basic infrastructure improvements. Going from 99.99% to 99.999% might require re-architecting your entire system. The cost and complexity increase exponentially with each nine. As the Google SRE book puts it, the last 0.1% of reliability is often more expensive than the first 99.9%.

Key Takeaways

• 99.9% uptime allows about 8 hours and 46 minutes of downtime per year, roughly 43 minutes per month.
• 99.99% uptime allows about 52 minutes per year, only about 4 minutes and 19 seconds per month.
• Each additional nine represents a 10x reduction in allowed downtime and a roughly 10x increase in engineering difficulty.
• Calculate your actual uptime from incident logs using the formula: (Total Time - Downtime) / Total Time x 100.
• Choose an uptime target based on business impact, not industry bragging rights. Not every service needs four or five nines.
• Read SLA fine print carefully, especially the exclusions for scheduled maintenance and force majeure.

References

• Beyer, B., Jones, C., Petoff, J., Murphy, N.R., Site Reliability Engineering, O'Reilly Media, https://sre.google/sre-book/table-of-contents/
• Google Cloud, "Defining SLOs," https://cloud.google.com/architecture/defining-SLOs
• AWS, "High Availability Architecture," https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/high-availability-and-scalability-on-aws.html