It's 2am. Your phone buzzes. It's not an alert — it's a customer, and they're not happy: "Is your site down? I've been trying to check out for an hour."
You scramble to a laptop. They're right. The site has been throwing errors since just after midnight, and you had no idea. Two hours of lost sales, a frustrated customer, and the sinking feeling that you were the last person to find out.
That feeling is exactly what uptime monitoring exists to prevent. If you've never set it up — or you're not sure your setup actually works — this guide is for you. No jargon, no assumptions.
What is uptime monitoring?
Uptime monitoring is a service that checks your website, API or server on a schedule and tells you the moment it stops working.
Think of it as a tireless assistant who visits your site every minute, around the clock, from different cities, and taps you on the shoulder the second something looks wrong — long before your customers notice.
That's the whole idea. The interesting part is in the details: what it checks, how often, from where, and how it decides something is actually broken.
Why it matters more than it sounds
"My site is usually fine" is a comforting thought right up until the one hour it isn't. And that hour is expensive in ways that aren't always obvious:
| What downtime costs | Why it hurts |
|---|---|
| Lost revenue | Every minute a checkout or signup is broken is money that simply doesn't arrive. |
| Lost trust | Customers who hit an error don't always come back — and some tell others. |
| SEO damage | If search engines crawl your site during an outage, rankings can slip. |
| Wasted time | Finding out late means debugging in a panic instead of catching it early. |
| Reputation | "Are they always down?" is a hard reputation to shake once it sticks. |
The real value isn't the downtime report — it's the head start. Knowing about a problem five minutes in, instead of two hours in, is the difference between a quiet fix and a public incident.
How it actually works
You don't need to understand the plumbing, but a mental model helps you trust (and tune) your setup.
- You create a monitor. You tell the service what to watch — say,
https://yoursite.com— and how often to check it (every 60 seconds is common). - It checks from the outside. The service sends a real request, the same way a visitor's browser would. Nothing to install on your servers.
- It checks from several places. Good monitoring runs from multiple locations around the world, so a hiccup on one network doesn't look like a global outage.
- It decides if something's wrong. A failed status code, a timeout, a missing keyword, an expired certificate — any of these can mean "down".
- It confirms, then alerts. Before waking you up, it re-checks from other locations. If the failure is real, you get notified; if it was a one-off blip, you don't.
That fifth step is the unsung hero. It's the difference between a monitor you trust and one you learn to ignore.
What can you actually monitor?
"Is the website up?" is just the start. Modern monitoring covers a lot more:
| Check type | Answers the question… |
|---|---|
| HTTP / website | Is the site loading, fast, and showing the right content? |
| API | Are my endpoints returning the right responses (with the right headers/body)? |
| Ping (ICMP) | Is the server reachable, and how's the latency and packet loss? |
| Port (TCP/UDP) | Is that specific service/port actually accepting connections? |
| DNS | Does my domain still resolve to the right place? |
| SSL certificate | Is my HTTPS certificate valid — and when does it expire? |
| Domain expiry | Is my domain registration about to lapse? |
| Email (SMTP / SPF / DMARC) | Can my mail server send, and is my email trusted? |
A surprising number of "the site is down!" emergencies are actually an expired certificate or a lapsed domain — both completely preventable with a monitor that watches the calendar for you.
The vocabulary you'll hear
A few terms come up constantly. Here's the plain-English version:
- Uptime — the percentage of time your service was working. Higher is better; it's usually quoted per month.
- Downtime — the opposite: time it wasn't working.
- Response time — how long your service took to reply. Slow can be as bad as down.
- The "nines" — shorthand for uptime targets. Each extra nine is roughly ten times harder to hit:
| Uptime | Allowed downtime per month |
|---|---|
| 99% | ~7 hours 18 minutes |
| 99.9% | ~43 minutes |
| 99.99% | ~4 minutes |
That table surprises people. "99% uptime" sounds excellent — until you realise it allows over seven hours of downtime a month. Knowing what the numbers really mean is half the battle.
What separates real monitoring from a checkbox
Plenty of teams "have monitoring" and still get surprised. The difference is in a handful of choices:
- Frequent enough checks — checking once an hour means you can be down for 59 minutes before anyone knows. Aim for every minute or two on what matters.
- Multiple locations — so you can tell "the site is down" from "one network had a bad moment".
- Confirmation before alerting — real problems verified from several places; blips ignored.
- Alerts that reach a human — email is fine, but route the urgent stuff to where you'll actually see it (SMS, Slack, a pager).
- The right checks — not just "is it up", but "is it fast", "is the cert valid", "did the page actually render".
- A status page — so when something does break, your customers can check for themselves instead of flooding your inbox.
Beginner mistakes to skip
| The mistake | Do this instead |
|---|---|
| Only checking the homepage | Monitor the journeys that earn money — checkout, login, key API calls. |
| Checking every 30 minutes | Check every 1–5 minutes on critical things. |
| Alerts only to one person's email | Use a team channel and an escalation path so nothing is missed. |
| Ignoring SSL and domain expiry | Add expiry monitors — these outages are 100% avoidable. |
| Trusting a single location | Confirm from multiple regions to kill false alarms. |
| "Set it and forget it" | Revisit what you monitor as your product grows. |
How to start in five minutes
You don't need a big project to get the most important 80%:
- Add an HTTP monitor for your main site or app. Check it every minute.
- Add a keyword check so a broken-but-200 page still counts as down.
- Add an SSL/certificate monitor and set it to warn you weeks before expiry.
- Point alerts at a place you'll see them — a team chat channel beats a buried inbox.
- Publish a simple status page so customers can self-serve during an incident.
That's it. Five monitors and you've gone from "find out from an angry tweet" to "find out first, fix it quietly".
The bottom line
| If you remember one thing… | …make it this |
|---|---|
| Uptime monitoring | is your early-warning system, not a report card. |
| The goal | is to hear about problems before your customers do. |
| Good setup | = frequent checks, multiple locations, confirmation, and alerts that reach a human. |
Uptime monitoring is one of those rare things that's cheap, quick to set up, and pays for itself the very first time it saves you from a 2am surprise.
When you're ready, our quick start walks you through your first monitor in a couple of minutes, and the monitors guide covers every check type in plain language. Future-you — the one who isn't woken up by an angry customer — will thank you.