What is uptime and why it matters

Definition: what exactly we measure

Uptime is the ratio of time the service responds as expected (typically HTTP 200, content contains a keyword) to the total measurement time. It's expressed as a percentage, most commonly over a 30- or 365-day period.

The opposite is downtime - the time when the service doesn't respond, returns 5xx, or takes longer than the set timeout. This also includes scheduled maintenance, unless you explicitly exclude it from the calculation (which you should communicate in the SLA).

The "nines" table: how much time each decimal place means

Each additional nine multiplies infrastructure costs. Five nines (99.999 %) is the domain of global providers with active cross-continent redundancy - for most business applications, 99.9 % is the right target.

What uptime you actually need

• Marketing site (company, portfolio): 99 % is enough. A visitor who arrives during an outage will try again later.
• SaaS app with a desktop client: 99.9 % is the minimum. Customers pay for work they can't do during downtime.
• E-shop, payment gateway, real-time service: 99.95 % and above. Every minute = direct losses.
• Infrastructure (an API used by others): At least 99.99 %. Your SLA caps your clients' SLA.

How uptime is measured

The monitoring service periodically calls your endpoint (typically HTTP GET, but also a TCP socket, ICMP ping or DNS resolution). Each check has a binary result: up or down.

A common interval is 1-5 minutes. The shorter it is, the faster you catch an outage, but the more false-positive alerts you get (a local network glitch, a brief deploy restart). The solution is multi-region checking: an outage is confirmed only when N regions report it, not just one.

Most common sources of "lost nines"

1. Expired SSL/TLS certificate. The browser blocks the page. Without monitoring, you find out Monday morning when the phone rings.
2. Domain expiry. The whole DNS stops working. Email, web and status page - everything falls at the same time.
3. Crashed database worker. The site returns 500 or times out for some requests. A classic ping might still pass, even though the application is broken.
4. DDoS or flooding. The server is overloaded, response time climbs above the limit, and monitoring reports an outage.
5. Botched deploy. A new version has a bug that breaks a path. Without integration tests, you find out when customers start complaining.

Conclusion

Uptime isn't a marketing number - it's a measure of how much you can rely on your own infrastructure. 99.9 % uptime isn't a luxury, it's a standard requirement for any service that generates revenue or has paying customers.

Step one is to measure. If you don't have external monitoring, technically you don't know what uptime you have - you're just guessing.

How to calculate uptime yourself

The formula is simple:

uptime % = (total time - downtime) / total time × 100

Say a check runs every minute over a 30-day month. That is 43,200 checks. If 40 of them came back down, downtime is roughly 40 minutes, so uptime is (43200 - 40) / 43200 × 100 = 99.907 %. The decimal places matter: the gap between 99.9 % and 99.99 % over a year is 8 hours 45 minutes versus 52 minutes of allowed downtime. That is the difference between "an afternoon offline" and "barely noticed". If you do not want to do the arithmetic by hand, our uptime calculator converts a target percentage into allowed downtime per day, month and year (and back).

Rolling window vs calendar window

There are two ways to report the same number, and they answer different questions: - Calendar window (this month, this year): resets on the 1st. Good for SLA reporting and invoicing, because the SLA credit period usually maps to a billing cycle. - Rolling window (last 24 h, last 7 days, last 30 days): always looks back a fixed amount from "now". Good for spotting a recent dip, because a bad hour does not get diluted by three weeks of green at the end of the month. A single outage looks very different in each. An outage on the 2nd of the month barely moves the calendar number by the 30th, but dominates a rolling 24-hour view all day. Mature monitoring shows both.

What counts as downtime (and what you exclude)

This is where uptime numbers quietly diverge between providers:

If you advertise an SLA, define these rules in writing. A customer who reads "99.9 %" and then experiences a two-hour maintenance window will dispute the number unless the contract says maintenance is excluded.

MTBF and MTTR: the numbers behind the percentage

Uptime percentage is the outcome. Two operational metrics explain why you land where you do: - MTBF (Mean Time Between Failures) - the average healthy stretch between outages. Higher is better. Driven by code quality, infrastructure redundancy and capacity headroom. - MTTR (Mean Time To Recovery) - how long an outage lasts on average. Lower is better. Driven almost entirely by how fast you find out. This is the lever monitoring pulls: an outage you learn about in one minute and fix in ten costs you 11 minutes; the same outage discovered by a customer phone call an hour later costs you 70. Shortening MTTR is usually cheaper than extending MTBF, and monitoring is the cheapest MTTR reduction there is.

A worked example: turning the dial

A team running at 99.5 % (about 3 h 39 min of downtime per month) wants to reach 99.9 %. They do not need new servers. An audit shows most of the downtime was one weekly deploy that broke a path for 40 minutes before anyone noticed, plus an SSL near-miss. Adding a keyword check on the critical path and SSL expiry alerts cut the discovery time from 40 minutes to under 2. The percentage moved from 99.5 % to 99.92 % without touching the infrastructure - purely by shortening MTTR.

Start measuring the uptime of your services

ePulz.io tracks your endpoints at intervals from 1 minute, from multiple regions. 7 days free.

Start monitoring →