On this page
Every online service fails eventually — a certificate lapses, a deploy goes sideways, a database fills its disk at 3 a.m. The only real question is whether you find out first, or your customers do. Uptime monitoring is how you make sure it's you.
The short version
- Uptime monitoring checks your service from outside your network on a schedule and alerts you when a check fails.
- A check is more than “is it up?” — it can verify status codes, keywords, response time, and certificates.
- Availability and response time are different signals; healthy services need both watched.
- Check frequency is a trade-off: faster detection versus more noise and cost.
- The hard part isn't detecting downtime — it's alerting on real problems without crying wolf.
What uptime monitoring actually is
Uptime monitoring is the practice of automatically requesting your service from somewhere outside your own infrastructure, at a regular interval, and recording whether it responded correctly. When a request fails — or several in a row do — the monitor notifies you through whatever channel you've chosen: email, SMS, Slack, a phone push, a webhook.
The word "uptime" gives it away: the goal is to measure how much of the time your service is actually available, and to catch the transitions from up to down as they happen. It's the smoke detector for your infrastructure. It doesn't put the fire out, but it makes sure you're awake for it.
Monitoring vs observability
How a single check actually works
Under the hood, an uptime check is a small, repeatable experiment. A worker somewhere on the internet performs a request against your target and grades the result against rules you set. For a website, the loop looks like this:
- Resolve and connect. The worker resolves your hostname to an IP and opens a connection. A failure here — DNS not resolving, connection refused, TLS handshake error — is already a meaningful signal.
- Send the request. For an HTTP monitor that's usually a
GETto your URL. The worker starts a stopwatch. - Grade the response. Did it return in time? Was the status code the one you expected (say
200)? If you asked it to, did the body contain a keyword like"logged in"or not contain"error"? - Record and decide. The pass/fail plus the response time is stored. If the state changed — a healthy service just failed, or a failing one recovered — that's when an alert fires.
That last step is the subtle one. Good monitoring alerts on transitions, not on every individual check, so a service that's been down for an hour doesn't page you sixty times. We wrote a whole piece on why a passing status code isn't always enough — a 200 OK can still mean your page is broken.
What you can actually monitor
"Uptime" is broader than pinging a homepage. The common check types, roughly from most to least familiar:
Application-layer checks
- HTTP / HTTPS — the workhorse. Verifies your site or API responds with the right status code, in time, optionally matching a keyword or a JSON field.
- SSL / TLS certificates — expiry is one of the most common self-inflicted outages, and one of the most avoidable. See monitoring certificate expiration.
- DNS — confirms a record resolves to the value you expect. Catches hijacks, propagation mistakes, and expired domains.
Network- and transport-layer checks
- TCP port — is the port open and accepting connections? Ideal for databases, mail servers, game servers, and anything that isn't HTTP.
- ICMP (ping) — is the host reachable at all? A blunt but useful bottom-layer signal.
The inverse: heartbeats
Uptime monitoring pulls — it reaches out to your service. But some things can't be reached from outside: a nightly backup, a cron job, a queue worker. For those you flip the direction with a heartbeat (a "dead man's switch"): the job pings you when it finishes, and you alert when an expected ping doesn't arrive. It's the only way to catch a job that fails silently. We cover it in monitoring cron jobs with heartbeats.
Availability vs response time
A service can be "up" and still be failing its users. These are two different health signals and you want both:
| Signal | Question it answers | What bad looks like |
|---|---|---|
| Availability | Did the check succeed at all? | Timeouts, 5xx errors, refused connections |
| Response time | How long did a successful check take? | A page that “works” but takes 8 seconds |
Watching only availability hides slow-burn degradation — the API that still returns 200 but has crept from 120 ms to 4 seconds as a database index rotted. Tracking response-time trends lets you catch that before it becomes an outage.
How often should you check?
Check interval is the first real trade-off you'll tune. Faster means you detect outages sooner; slower means less load, less cost, and fewer chances for a transient blip to look like a problem. A reasonable starting point:
| Interval | Good for | Trade-off |
|---|---|---|
| 30 seconds | Checkout, login, payment paths | Highest cost; most sensitive to blips |
| 1 minute | Most public sites and APIs | The sensible default |
| 5 minutes | Internal tools, low-stakes pages | Up to 5 minutes of undetected downtime |
Tip
The real hard part: avoiding false alarms
Detecting downtime is easy. Detecting it without waking you for every network hiccup is where monitoring earns its keep. Three techniques do most of the work:
- Confirmation. Require two or three consecutive failures (or a re-check from a second location) before declaring an outage. A single dropped packet shouldn't page anyone.
- Multiple vantage points. Check from several regions and apply a rule — down only if a majority agree. One failing region usually means a network path problem, not your site.
- Alert on transitions, then be quiet. Notify on the up→down and down→up edges, not on every failed check in between.
Get this wrong and you get alert fatigue — the state where your team mutes the channel because it cries wolf, and then misses the real fire. It's common enough that we devoted a guide to it: alerts that don't cry wolf.
Getting started
You don't need a platform migration to start. A sane first setup takes about ten minutes:
- Monitor the four things customers actually touch: your homepage, your login, your health endpoint, and the money path (checkout, signup, or your core API call).
- Add certificate-expiry monitoring for every HTTPS host — it's free insurance.
- Route alerts to a channel you'll actually see, and set a confirmation threshold so you're only paged on real transitions.
- Add a heartbeat for your most important scheduled job — the backup you'd hate to discover was silently failing.
That covers the outages that hurt most, for the least effort. From there you expand: more endpoints, response-time budgets, multi-region checks, a public status page. If you want the full checklist, the free Web Monitoring Playbook lays out the twelve monitors every site should have.
Frequently asked questions
- What is uptime monitoring, in one sentence?
- Uptime monitoring is the practice of automatically checking a website, API, or service from outside your network at a regular interval, and alerting you the moment a check fails — so you learn about an outage from a tool, not from an angry customer.
- How often should uptime checks run?
- For most public sites, every 60 seconds is a good default. Revenue-critical paths justify 30 seconds; low-stakes internal tools can check every 5 minutes. Faster checks detect outages sooner but add load and cost, so match the interval to what a minute of downtime actually costs you.
- Is uptime monitoring the same as a status page?
- No. Uptime monitoring is the detection system that watches your services and pages you privately. A status page is the public communication surface that tells your users what's happening. They work together: monitoring detects the incident, the status page announces it.
- Do I need to install anything on my server to monitor uptime?
- No. Uptime checks run from an external network against your public URL or host, so there's nothing to install. You only need an agent when you want inside-the-box metrics like CPU, memory, and disk — which is a separate, complementary kind of monitoring.