What Is Uptime Monitoring? From Check to Alert
Uptime monitoring checks a service from outside on a schedule and keeps the history. Here is how a failed check becomes an incident, and how fast.
Uptime monitoring is the practice of checking a service from outside itself, on a fixed schedule, and alerting when the answers stop matching what you expect. It keeps the history of those answers, which is what turns a yes-or-no into a percentage. The step most definitions skip is the middle one: how a failed check becomes an incident.
What one check consists of
A single check is a request and a verdict. A probe in some region opens a connection, sends the request a client would send, waits for a reply, and compares that reply against a rule you set.
For an HTTP target the rule is usually a status code. RFC 9110 defines the classes, and a check normally accepts 200 and rejects anything in the 5xx range. It can also assert on a keyword in the body, a response time ceiling, or the days left on the certificate.
The timing is recorded in pieces, not as one number: DNS resolution, TCP connect, TLS handshake, time to first byte, then content download. A slow result is therefore attributable. You can tell a slow resolver apart from a slow application without guessing.
How does a failed check become an incident?
Through confirmation, not immediately. One failed check is a blip, and treating it as downtime is the single most common cause of alerts nobody trusts.
The usual model is a small state machine. A target sits in UP. One failure moves it to SUSPECT rather than DOWN. Another region is asked to try the same request, and only when independent probes agree does the state become DOWN and an alert fire. On the way back it passes through RECOVERING, so one lucky success does not declare victory.
One distinction matters here and is easy to miss. If the probe itself cannot complete the attempt, that is a probe error, not a vote that the target is broken. Counting infrastructure faults as target failures is how a monitoring outage turns into a false page. Every uptime monitoring product implements some version of this pipeline, and the parameter names differ far more than the idea does.
How fast will it actually notice?
Slower than the interval, always. The worst case is the interval plus however many confirmation cycles you require, because a failure can start one second after a successful check.
| Interval | Cycles before alerting | Worst-case detection |
|---|---|---|
| 30 seconds | 2 | about 90 seconds |
| 1 minute | 1 | about 2 minutes |
| 1 minute | 2 | about 3 minutes |
| 5 minutes | 2 | about 15 minutes |
We prefer a 60-second interval with two cycles for anything customer-facing. It costs a minute of detection against the aggressive setting and removes most of the false pages. Free accounts run at a one-minute interval as of September 2026, so that configuration is available without paying.
What can be checked this way
Not just web pages. Uptime monitoring applies the same schedule-and-verdict loop to anything that answers a request, which in practice means ten distinct check types.
| Type | What it asks | Typical use |
|---|---|---|
| http and api | a request against a status or assertion | sites and endpoints |
| keyword | is this string still in the body | a payment form that vanished |
| tcp and udp | does the port accept a connection | brokers, databases, game servers |
| dns | does the record resolve to the expected value | after a registrar change |
| ping | does the host answer ICMP | network reachability only |
| ssl and domain | how many days until expiry | the outage you can diary |
| heartbeat | did the job check in on time | cron and batch work |
Heartbeat is the odd one out and the most useful exception. It reverses the direction: the job posts to a URL when it finishes, and the absence of that post is the signal. An outbound check can never see a job that simply never ran.
Monitoring uptime is not the same as checking it
A checker answers one question once. You paste a URL, it tells you whether the site responds right now, and nothing is retained. That is useful for a single argument about whether a problem is yours or theirs.
Monitoring keeps the series. Retention is what makes an availability figure calculable at all, and what lets you say a service is slower this week than last. Free accounts hold one month of history as of September 2026, with a year on the paid tier. How that history becomes a number, and what counts as planned work, is worked through in our piece on measuring downtime. The arithmetic of the nines lives in five nines uptime.
What uptime monitoring will never tell you
It watches from outside, so it sees results and not causes. A queue backing up, a heap filling, a replica falling behind: none of those are visible until they change a reply somebody receives. Diagnosing them needs instrumentation inside the process.
That boundary is deliberate rather than a shortfall. Google's SRE book makes the case for paging on symptoms and investigating with everything else, and the outside view is the cleanest symptom signal available. The trade-offs of the outside-in position are covered in blackbox monitoring.
Treat uptime monitoring as the layer that decides whether to wake somebody, and let other tools explain what happened once they are awake. Start with your most important hostname, a one-minute interval and confirmation from a second region, then widen. Egress addresses for every region are listed on the probe IPs page if you filter at the edge, and ten checks fit inside the free plan as of September 2026.
FAQ
It is the practice of sending a scheduled request to a service from outside it, comparing the reply against a rule, and alerting when the comparison fails. The history of those replies is retained, which is what makes an availability percentage calculable. Checks run at a fixed interval rather than continuously, so detection is never instant.
For most web services 99.9 percent is a reasonable target, which allows about 43 minutes of unavailability a month. Going beyond that costs disproportionately more in redundancy and process. The figure only means something alongside a measurement window and a definition of what counts as down, because both change the result substantially.
No. Uptime is a measurement and an SLA is a contract that puts a promise and a penalty around one. A provider can report 99.99 percent uptime with no SLA at all, and an SLA can set a target well below what a service actually achieves. The two numbers are chosen for different reasons.
At worst, the check interval plus the confirmation cycles you require. A failure can begin just after a successful check, so a one-minute interval needing two confirming cycles detects within roughly three minutes. Shortening the interval speeds detection up and increases the false-positive rate unless confirmation stays in place.
No. An external check sees only what a client receives, so queue depth, memory pressure and replica lag stay invisible until they change a response. That needs instrumentation running inside the process. External checks are best used to decide whether to alert, with internal tooling used to explain what happened.
Related reading
- Downtime: What It Means and How to Measure It - Downtime is any period a system is unavailable, but the percentage only means something once you state where you measured from and what counted.
- Blackbox Monitoring: What the Outside View Sees - Blackbox monitoring tests a service from outside with no access to its internals, which is how you catch DNS, TLS and routing failures.
- Five Nines Uptime: What 99.999% Really Costs - Five nines means 99.999% availability, about 5 minutes 15 seconds of downtime a year, and a budget smaller than most checks can resolve.