---
title: Uptime Monitoring 101: how to never be the last to know
description: The worst way to find out your website is down is from an angry customer. This is the beginner-friendly guide to uptime monitoring — what it is, why it matters, and how to set it up so you always hear it first.
canonical: https://watchfor.io/blog/uptime-monitoring-101
---

# Uptime Monitoring 101: how to never be the last to know

2026-06-23 · WatchFor Team · Monitoring · monitoring, basics, uptime

The worst way to find out your website is down is from an angry customer. This is the beginner-friendly guide to uptime monitoring — what it is, why it matters, and how to set it up so you always hear it first.

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.

1. **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).
2. **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.
3. **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.
4. **It decides if something's wrong.** A failed status code, a timeout, a missing keyword, an expired certificate — any of these can mean "down".
5. **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%:

1. **Add an HTTP monitor** for your main site or app. Check it every minute.
2. **Add a keyword check** so a broken-but-200 page still counts as down.
3. **Add an SSL/certificate monitor** and set it to warn you weeks before expiry.
4. **Point alerts at a place you'll see them** — a team chat channel beats a buried inbox.
5. **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](/docs/quick-start) walks you through your first monitor in a couple of minutes, and the [monitors guide](/docs/monitors) covers every check type in plain language. Future-you — the one who *isn't* woken up by an angry customer — will thank you.

---

Canonical page: https://watchfor.io/blog/uptime-monitoring-101 · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt