Website Uptime Explained: Availability Percentages, SLA Math, and Downtime Impact
Website uptime is the percentage of time a server delivers valid HTTP responses, expressed in “nines” of availability. The difference between 99.9% and 99.99% is not 0.09% — it is the difference between 8.7 hours and 52 minutes of downtime per year.
Uptime % = (Total Time − Downtime) ÷ Total Time × 100
A server is “up” only when it returns a valid HTTP 200–399 response within the probe timeout. A process that is running but returning HTTP 500, timing out, or failing DNS resolution is counted as downtime — regardless of what the server’s process monitor reports.
The Mathematical Definition of Uptime and Availability
Website uptime is the ratio of time during which a server successfully responds to probe requests, expressed as a percentage of total elapsed time. The industry standard for expressing uptime uses “nines notation” — the number of 9s in the percentage — because the difference between availability tiers compounds dramatically as you add each nine. Moving from two nines (99%) to three nines (99.9%) reduces annual downtime by 78.8 hours. Moving from three nines to four nines (99.99%) reduces it by a further 8.2 hours.
The formula is simple; the precision of what counts as “downtime” is where implementations diverge. A probe-based uptime monitor counts a measurement window as downtime if the HTTP probe does not receive a valid HTTP 200–399 response within the timeout. This means a server returning HTTP 503 (service unavailable), HTTP 500 (internal server error), or no response within 10 seconds is counted as down — even if the TCP connection succeeds, even if the process is running, even if other endpoints on the same server are responding. Uptime measured this way is a true measure of user-facing availability, not internal process health.
The practical implication: your hosting dashboard showing “server running” does not mean your service has 100% uptime. A crashed application returning 500s while the web server process stays alive will show as 0% uptime in probe-based monitoring while showing as operational in infrastructure monitoring. This distinction is why external uptime monitoring from independent infrastructure is the only reliable measurement of actual user-facing availability.
How to Calculate Downtime From Uptime Percentage
Each additional “nine” in your availability percentage reduces allowable downtime by roughly 90% relative to the previous tier. The table below shows the exact downtime budget for each availability level across all standard measurement periods. These are the numbers behind every hosting SLA.
| Availability | Nines | Downtime / Year | Downtime / Month | Downtime / Week | Downtime / Day |
|---|---|---|---|---|---|
| 90%1 nine | One nine | 36d 12h 0m | 73h 0m | 16h 48m | 2h 24m |
| 99%2 nines | Two nines | 3d 15h 36m | 7h 18m | 1h 40m | 14m 24s |
| 99.5% | — | 1d 19h 48m | 3h 39m | 50m 24s | 7m 12s |
| 99.9%3 nines | Three nines | 8h 45m 36s | 43m 49s | 10m 4s | 1m 26s |
| 99.95% | — | 4h 22m 48s | 21m 54s | 5m 2s | 43s |
| 99.99%4 nines | Four nines | 52m 35s | 4m 22s | 1m 0s | 8.6s |
| 99.999%5 nines | Five nines | 5m 15s | 26s | 6s | 0.86s |
| 99.9999%6 nines | Six nines | 31s | 2.6s | 0.6s | 0.09s |
The most important number in this table for most web services: 99.9% uptime (three nines) allows 8 hours and 45 minutes of downtime per year. That is the SLA tier most commonly offered by shared hosting, managed WordPress hosts, and entry-level cloud services. For e-commerce or SaaS applications where downtime directly translates to lost revenue, three nines is often insufficient — four nines (52 minutes/year) is the practical minimum for production systems processing real transactions.
Five nines in practice: 99.999% uptime (5 minutes 15 seconds of downtime per year) requires active-active redundancy across multiple data centers with automatic failover completing in under 30 seconds. This is only achievable with dedicated engineering investment in infrastructure redundancy — not a configuration you purchase from a hosting provider. AWS, Google Cloud, and Azure advertise this only for specific multi-region services, not their standard single-region offerings.
What Does an SLA (Service Level Agreement) Actually Guarantee?
An SLA contractually commits a provider to a minimum monthly uptime percentage and specifies service credits as the remedy if that threshold is breached — it does not guarantee zero downtime, and it does not cover revenue losses from downtime. The SLA is an accountability mechanism and a compensation schedule, not a technical guarantee of continuous operation. Understanding the exact language of an SLA — what counts as downtime, what the exclusions are, and what credits you receive — determines whether an SLA actually protects your business.
Three elements define every SLA: the uptime commitment (e.g., 99.9% monthly), the measurement methodology (how the provider measures uptime — typically their own internal monitoring, not independent probes), and the credit schedule (the service credits offered for SLA breaches, typically 10–30% of monthly fees proportional to the severity of the breach). Most SLAs explicitly exclude several categories from downtime calculations: scheduled maintenance windows (announced in advance), downtime caused by customer actions, force majeure events, DDoS attacks above a certain volume, and third-party service failures outside the provider’s control.
The most important SLA detail most customers overlook: providers measure their own uptime using their own internal monitoring, not from the customer’s perspective. A provider whose internal probes show 99.95% uptime may be providing 99.5% uptime from the user’s perspective if there are network path issues between the provider and end users, CDN edge failures, or DNS resolution problems that the provider’s internal probes bypass. Independent external uptime monitoring from a tool like DownCheck gives you the actual uptime figure from the user’s perspective — the only metric that matters for SLA claims and business impact assessment.
SLA credits are not compensation for revenue loss. A 30% service credit on a $100/month hosting plan = $30. If your e-commerce store generates $10,000/hour in revenue and is down for 2 hours, the SLA credit covers 0.06% of your actual loss. SLAs protect the provider legally, not the customer financially. Run your own uptime monitoring to measure and document actual downtime independently of provider reports.
Uptime vs Availability vs Reliability — The 3 Are Not the Same
These three terms are used interchangeably in marketing materials but represent distinct engineering concepts. Conflating them leads to SLA misunderstandings, incorrect system design, and misleading dashboards. Each measures a different property of a system’s behavior over time.
Uptime
The percentage of elapsed time during which the system is in an operational state and responding to probe requests with valid HTTP responses. Measured by external probes at fixed intervals.
A system can have high uptime but poor availability if it is technically “up” but returning errors for a subset of requests, or responding slowly enough to be effectively unusable.
Availability
The probability that the system is operational and correctly serving requests at any given moment. Availability extends uptime by accounting for partial degradation — a system that is “up” but serving 40% error rates has low availability despite high uptime.
True availability measurement requires checking not just reachability but correctness of responses across all service endpoints, not just the homepage.
Reliability
The probability that the system will perform its required functions without failure for a specified duration under stated conditions. Reliability is about failure frequency and duration, expressed as MTBF (Mean Time Between Failures).
A system can have 99.9% uptime but poor reliability if it fails frequently for short durations — many small failures that each miss the SLA threshold individually but represent significant operational instability.
The practical implication: an SLA stating “99.9% uptime” does not guarantee 99.9% availability of all features. A provider’s API may be up (homepage returns 200) while database reads are failing for 20% of requests. The homepage probe returns 200; the SLA is technically met; your users cannot complete their tasks. This is why enterprise SLAs often include separate commitments for specific services or endpoints — a storage SLA, a compute SLA, and a network SLA, each measured independently rather than as a single aggregate number.
MTTR and MTBF — Mean Time to Repair and Mean Time Between Failures
MTBF and MTTR are the two reliability metrics that, together, fully describe a system’s failure behavior and determine its long-run availability without requiring continuous measurement. While uptime percentage tells you the outcome, MTBF and MTTR tell you the mechanism: how often does the system fail, and how quickly does it recover? These metrics drive architectural decisions — you improve availability either by failing less often (higher MTBF) or by recovering faster (lower MTTR).
The average operational time between consecutive failures. Calculated by dividing total operational time by the number of failures in a measurement period.
A server that runs for 720 hours between failures has MTBF = 720 hours. Higher MTBF = more reliable system. Improved by eliminating failure causes: hardware redundancy, code quality, capacity planning, chaos engineering.
The average time from the start of a failure event to full service restoration. Encompasses detection time, diagnosis time, repair/rollback time, and verification time.
A team that detects failures in 2 minutes (via monitoring alerts) and rolls back deployments in 3 minutes has a lower MTTR than a team relying on user reports and manual deployments. Improved by alerting systems, runbooks, and automated recovery.
This formula reveals a critical insight: improving MTTR has a disproportionate impact on availability when MTBF is already high. If your system fails once per month (MTBF = 720h) and your MTTR is 2 hours, your availability is 99.72%. Cutting MTTR to 10 minutes raises availability to 99.98% — nearly four nines — with zero reduction in failure rate. This is why high-availability systems invest heavily in automated rollback, feature flags, circuit breakers, and real-time alerting rather than exclusively in preventing failures. Uptime monitoring directly reduces MTTR by cutting detection time from minutes to seconds.
Real-World Uptime Numbers: AWS, Google Cloud, Cloudflare, Azure
Cloud provider SLA commitments and actual measured uptime are two different numbers — the SLA is the contractual floor, while actual uptime is typically higher for core services but varies significantly by service tier and region. Understanding both the committed SLA and the historical incident record for each major provider is essential for architecture decisions: choosing where to host, which services to build redundancy against, and which provider’s failures have historically caused the most widespread impact.
SLA for EC2, S3, RDS (Multi-AZ). Single-AZ EC2 SLA is 99.5%. The us-east-1 region has the highest incident rate due to its concentration of legacy infrastructure and the density of services it hosts.
Cloudflare’s network SLA for Enterprise plans. Their anycast network (300+ PoPs) provides inherent redundancy. Global outages are rare but catastrophic in impact — a single BGP misconfiguration took down 19% of internet traffic in June 2022 for 37 minutes.
SLA for GCE instances and GKE. Google’s global fiber network provides strong cross-region resilience. Historically fewer large-scale incidents than AWS, but Gmail/Workspace outages have affected hundreds of millions of users during rare incidents.
SLA for Virtual Machines in Availability Zones. Azure Active Directory outages (2021, 2022) caused cascading authentication failures across Microsoft 365, Teams, and all Azure-integrated enterprise applications globally.
Edge deployment platforms. Both are built on top of AWS and Cloudflare infrastructure, meaning their actual availability is bounded by those providers’ uptime. Vercel’s edge network has experienced several incidents affecting Next.js deployments globally.
Fastly’s June 2021 global outage lasted 49 minutes and took down Amazon, Reddit, GitHub, Twitch, the UK government website, and the New York Times simultaneously — all Fastly CDN customers. Root cause: a single customer configuration change triggered a bug affecting 85% of Fastly’s network.
The concentration risk principle: Using a single CDN, a single cloud provider, or a single DNS provider as your only infrastructure layer means that provider’s incidents become your incidents. High-availability architectures use multi-CDN routing, multi-region active-active deployments, and secondary DNS providers to ensure no single provider’s failure causes a complete outage.
How DownCheck Measures 5-Minute Interval Uptime for 55+ Services
DownCheck measures uptime by dispatching active HTTP probe requests at 5-minute intervals from independent infrastructure, recording the result of each probe window as either “up” or “down” based on the HTTP response received within the 10-second timeout. This probe-based methodology captures true user-facing availability — not server process health, not infrastructure metrics, but the binary question that matters: “Can a user actually reach this service right now?”
Probe dispatched every 5 minutes
An HTTP/HTTPS request is sent to the target URL from Railway-hosted infrastructure (US region). The probe follows up to 5 redirects and establishes a full TLS connection on HTTPS targets. Timeout: 10 seconds. The 5-minute interval means a complete outage is detected within 5 minutes of onset in the worst case, and within seconds if monitoring is real-time.
Response evaluated against validity criteria
A probe window is counted as “up” only if the HTTP response status code is 200–399 and the response is received within 10 seconds. Any status code of 400+ or a response timeout is recorded as a “down” measurement. This ensures that a server returning 503 (Service Unavailable) or 502 (Bad Gateway) is correctly counted as downtime, not as an operational measurement.
Uptime percentage calculated across rolling windows
Uptime is calculated as: (successful probe windows ÷ total probe windows) × 100. DownCheck tracks this across 24-hour, 7-day, and 30-day rolling windows for each monitored service. A 5-minute interval generates 288 probe windows per day — statistically sufficient to detect even brief outages and calculate accurate uptime percentages.
Results stored and aggregated for 55+ services
DownCheck continuously monitors 55+ major services including AWS, Google Cloud, Cloudflare, GitHub, Stripe, Shopify, and others — storing probe results in a Cloudflare D1 database. This historical data powers the status timeline displayed on each service’s page and allows trend analysis of uptime patterns across providers.
Why 5-minute intervals? One-minute intervals provide faster detection but generate 6× more probe traffic and infrastructure cost. Five-minute intervals strike the balance between detection speed and sustainability for continuous monitoring at scale. For services where downtime cost is high, DownCheck’s on-demand checks allow you to run an immediate real-time probe at any moment, bypassing the interval schedule entirely and getting results within seconds via the 3-probe architecture.
Frequently Asked Questions
See your uptime right now
DownCheck runs an HTTP probe and 4-resolver DNS consensus and shows you whether a site is up — with confidence scoring, response time, and DNS verification.
Check a site →