Setting up uptime monitoring badly is easy: one ping on the homepage, alerts to an unwatched inbox, done. This guide sets it up properly — the checks that catch real failures, the intervals that catch them fast, and the alerting that gets a human moving. (New to the concept? Start with what is uptime monitoring.)
Step 1 — Choose your monitoring tool
Three honest paths:
- Free hosted — Better Stack (10 monitors, business use OK) or UptimeRobot (50 monitors, personal use). Five-minute setup, zero cost. Full comparison: best free uptime monitoring tools.
- Self-hosted — Uptime Kuma in a Docker container: unlimited monitors, free forever. Rule: run it on infrastructure independent of what it monitors — a monitor that dies with your server is decoration.
- Paid hosted — from ~$7–29/month you get 30–60-second intervals, SMS/phone alerts and status pages. The moment downtime costs real money, this is cheap. Options ranked in our best uptime monitoring tools guide.
Step 2 — Set up the four check layers
Layer 1: HTTP checks on pages that matter. Homepage, login page, checkout/pricing page, and your API’s health endpoint. Expect a 200; alert on anything else. Don’t monitor every page — monitor every revenue path.
Layer 2: one keyword check that exercises the backend. An HTTP 200 can lie: the server responds while the app behind it is broken. Point a keyword check at a page that touches your database (a product page, a search result) and verify real content appears. This single check catches the “site up, app down” class of failure that pure pings miss.
Layer 3: SSL and domain expiry. Certificate and domain expiries are the only outages with a published date. Alert at 30, 14 and 7 days. Every serious tool includes this — turning it on takes one minute and prevents the most embarrassing outage type there is.
Layer 4: heartbeats on scheduled jobs. Backups, cron jobs, queue workers — things that fail silently. Reverse the logic: the job pings the monitor on completion; a missing ping raises the alert. This is the only reliable way to catch a backup that stopped running three weeks ago.
Step 3 — Pick intervals deliberately
The interval is your worst-case detection time:
| Interval | Worst-case detection | Suits |
|---|---|---|
| 30s | ~1 min (with confirmation) | Revenue-critical (e-commerce, SaaS, APIs) |
| 1 min | ~2 min | Business sites |
| 5 min | ~6+ min | Blogs, side projects, free tiers |
Short outages are real: a 3-minute deploy hiccup is invisible to a 5-minute check and fully logged by a 30-second one. Faster intervals are mostly a paid feature — that alone is the strongest reason to pay. E-commerce sites have the tightest case here (see website monitoring for e-commerce).
Step 4 — Design alerts a human will act on
Checks find problems; alerting gets them fixed. The rules that matter:
- Confirm before alerting. Require verification from a second location (or 2 consecutive failures) so a checker’s network blip doesn’t page anyone.
- Escalate in stages. Slack/email at detection → SMS/phone to the on-call person after 5 minutes unacknowledged. Every decent tool supports this; most people never configure it.
- Route by severity. Checkout down = phone immediately. Blog slow = Slack tomorrow-morning channel. One severity level for everything guarantees either panic or numbness.
- Alert on recovery too — closure matters, and outage duration feeds your postmortems.
- Never a dead inbox. An alert nobody sees is an outage nobody fixes.
Step 5 — Add the layers pings can’t cover
- Response-time alerting: slow is the new down — a 10-second page load loses users as surely as a 500. Set degradation thresholds, not just up/down.
- A status page: tell users before they tell you. Most tools bundle one; dedicated options in best status page tools.
- Scripted user journeys: login → cart → pay, run in a real browser from multiple regions. That’s synthetic monitoring — the natural next step once the basics are solid.
- Server internals: uptime checks say that it broke; server monitoring says why.
The 15-minute starter recipe
- Sign up for a free tier (Better Stack) or
docker runUptime Kuma. - HTTPS checks: homepage + most important endpoint, 1–5 min interval.
- Keyword check on a database-backed page.
- SSL + domain expiry alerts at 30/14/7 days.
- Heartbeat on your backup job.
- Alerts → Slack channel people actually read; add phone escalation when you upgrade.
That setup catches the large majority of real-world outages — and it costs nothing to start today.