What Is Uptime Monitoring? How It Works and What 99.9% Really Means

Uptime monitoring is an automated service that checks your website, API or server at a fixed interval and alerts you as soon as it stops responding correctly. It answers one question around the clock: can people reach this right now? It also records how long each response took, so over time you get a precise history of availability and speed.

This guide explains how uptime checks work, how to choose an interval, why good services confirm failures from more than one place and what uptime percentages mean in practice.

How an uptime check works

A monitoring service sends a request to your site from its own servers, just like a visitor would, and evaluates the answer. Depending on what you monitor, the check can be:

• HTTP(S): requests a URL and looks at the status code, the response time and, if you want, the content of the response. This is the standard check for websites and APIs.
• Ping: sends an ICMP echo to see whether a host is reachable on the network.
• Port: opens a connection to a specific TCP port, for example 465 for SMTP over TLS or 3306 for a database, to see whether the service is listening.

An HTTP check passes when the response arrives in time and matches what you expect. By default that means a successful status code. A better check also looks at the content. A page can return status 200 and still show “Database connection error”. Validating that the response contains a word that only appears on a working page, or that an API returns the field you expect, catches those cases. With Uptimecheck you can set the HTTP method, headers, request body, basic auth and the expected response for each uptime monitor or API monitor.

From a failed check to an alert

A single failed request is not always an outage. A packet can get lost between two networks, or a server can hiccup for a second. If every failure triggered an alert, people would soon start ignoring them. That is why a well-built check runs in steps:

1. A check fails, for example with a timeout or a 503.
2. The service checks again, ideally from a second region.
3. If the failure is confirmed, an incident opens and alerts go out.
4. When checks pass again, a recovery notice goes out with the total downtime.

Checking from two regions does two things. It filters out false alarms caused by one network path, and it shows when an outage is regional: if your site fails from Europe but works from the US, the problem is probably in routing or a CDN edge, not in your server. Uptimecheck checks from Europe and checks a failed request again a few seconds later before an incident opens, so one blip does not page anyone.

Choosing a check interval

The interval is the longest time an outage can go unnoticed. With a five-minute interval, a failure that starts right after a check is found up to five minutes later, plus confirmation time. With one-minute checks, it is found within about a minute.

As a rule of thumb:

• Every minute for anything that earns money or serves customers: shops, SaaS products, booking systems, APIs.
• Every five minutes for personal projects, internal tools and sites where a few extra minutes do not matter.

Uptimecheck runs checks every minute on every paid plan. See the pricing for details.

What uptime percentages mean in minutes

Uptime is usually expressed as a percentage of time. The numbers look close together, but the difference in real downtime is large. Over a year:

• 99% allows 3 days, 15 hours and 36 minutes of downtime.
• 99.9% allows 8 hours, 45 minutes and 36 seconds.
• 99.99% allows 52 minutes and 34 seconds.

Per month, 99.9% is about 43 minutes. That might be one long incident or many short ones. Monitoring tells you which, and that matters, because the fix is different. One long outage points to a single failure. Many short ones often point to an overloaded server or a flaky dependency.

What to monitor

Most teams start with the homepage. That is a good start, but the homepage is often cached and the last thing to fail. A useful set of monitors covers:

• The pages that earn money: checkout, signup, booking.
• The login page, which depends on the database and session storage.
• Public APIs your apps and integrations depend on.
• Supporting services such as mail servers and databases, with port checks.
• The things that expire: SSL certificates and domains.
• Scheduled jobs, with heartbeats, because a failed backup does not take your site down but still needs an alert.

Where alerts should go

An alert only helps if it reaches someone who can act. Email works for most alerts during the day. For outages at night, a channel that pushes to a phone is harder to miss. Team chats such as Slack, Discord, Telegram or Microsoft Teams keep everyone informed and give the incident a shared place for discussion. Webhooks let you send alerts into your own systems. Uptimecheck sends alerts to email, Slack, Discord, Telegram, Microsoft Teams and webhooks on every plan. See notifications.

Uptime monitoring checklist

1. List the pages, APIs and services that matter, starting with the ones that earn money.
2. Add an HTTP(S) monitor for each, with content validation on the most important ones.
3. Choose a 1-minute interval for business-critical checks.
4. Check from more than one region.
5. Send alerts to at least two channels, one of them suitable for nights.
6. Add SSL, domain and heartbeat monitors for everything that can expire or stop quietly.
7. Publish a status page so customers can see what is happening during an incident.
8. Review incident history and response times every month.

Summary

Uptime monitoring turns “the site might be down” into “the site has been down for two minutes, here is the error, and the right person already knows”. Choose a short interval, confirm failures before alerting, validate content as well as status codes and send alerts where they will be seen.

Uptimecheck covers websites, APIs, servers, cron jobs, DNS, SSL and domains in one account at a fixed price. Try it free for 14 days, no credit card required.