What website monitoring actually is
At its simplest, website monitoring is an outside-in check: a request sent to your site from somewhere that isn't your own servers, on a repeating interval, checking for a specific signal — usually "did I get a 200 response back within a reasonable time." That single check already catches the most common failure: the server is unreachable, timing out, or returning an error page instead of your site.
Real monitoring goes further than a bare up/down ping. It checks response time (so a site that "loads" in 12 seconds still counts as a problem), the TLS certificate (so you find out about an expiring cert weeks before browsers start warning visitors), DNS resolution (so a misconfigured record doesn't sit undetected), and increasingly the content of the response itself — a 200 status code with an error message in the body is still a broken page.
The point isn't exotic checks. It's checking from outside your own infrastructure, on a schedule tight enough that an outage is caught in minutes rather than discovered by a support ticket.
What to monitor first
If you're starting from nothing, monitor these in order: (1) the homepage and any other URL a customer would hit directly — login, checkout, the marketing site itself; (2) TLS certificate expiry, because it fails silently until the day it doesn't; (3) domain expiry, for the same reason; (4) DNS records, if you've ever had a DNS provider change something without telling you; (5) any API endpoint another service depends on, since those failures are invisible to a human browsing the site.
A single site with one primary URL, TLS, and domain covers the highest-value 80% of what can silently break. Everything past that — DNS, email authentication records (SPF/DMARC), individual API routes — is worth adding once the basics are covered, not before.
The production monitoring checklist
Use this as the first production checklist for a small site or SaaS app. You do not need every possible monitor on day one; you need coverage for the failures that make customers write to you first.
1. Public reachability: monitor the homepage or primary marketing URL from outside your infrastructure. This catches DNS failures, server outages, bad deploys, and routing mistakes that make the whole site disappear.
2. Customer path: monitor the one URL a paying user needs most — login, checkout, dashboard, booking flow, or API health endpoint. A homepage can be green while the money path is broken.
3. Trust signals: monitor TLS expiry, domain expiry, redirects, and DNS. These are boring until the day they fail, and then browsers, email providers, or customers block you before your app code even runs.
4. Silent internal work: add heartbeat monitors for cron jobs, queues, scheduled imports, and backups. Outside-in checks cannot see a queue worker that died on Friday or a backup job that stopped three weeks ago.
5. Alert ownership: route alerts to a person or channel that is actually watched, require consecutive failures before paging, and write down who owns the monitor. A monitor without an owner is just a log entry.
6. Customer communication: if customers depend on the service, connect monitors to a status page. When the site is down, a clear incident page saves support time and shows that someone is already working the problem.
Alert rules that don't cry wolf
The fastest way to make monitoring useless is to alert on the first failed check. Networks have transient blips that have nothing to do with your site being down — a single failed request from a single probe location is normal background noise, not an incident.
A workable rule: require two or three consecutive failed checks, ideally from more than one probe location, before firing an alert. That turns "noisy and ignored" into "rare and trusted." Pair it with a check interval that matches how much downtime you can tolerate before someone should know — every 5 minutes for anything customer-facing, every 15–30 minutes for internal tools where a short gap doesn't matter.
Response-time alerts need their own threshold, separate from the down/up check — a site that's "up" but taking 8 seconds to respond is a real problem that a binary uptime check will never catch.
Mistakes that let outages slip through
Monitoring only the homepage. If checkout, login, or your API are separate paths, an outage confined to one of them won't show up on a homepage-only check.
Checking from one location only. A single vantage point can't tell the difference between "my site is down" and "this one network route is down." Checking from a few different probe locations rules that out.
No one owns the alerts. A monitor that pages a Slack channel no one reads, or an inbox that's filtered to a folder, isn't monitoring — it's a paper trail after the fact. Alerts need a real destination and a real owner.
Treating "no alert" as "everything's fine." A monitor that's misconfigured, paused, or silently failing to run looks identical to a healthy site — until the day it matters. This is why heartbeat-style checks (see our guide on cron monitoring) matter alongside outside-in checks: they confirm the monitoring itself is still running, not just the thing it watches.
How Holter does it
Holter runs outside-in checks — uptime, response time, TLS, DNS, and related signals — from multiple probe locations, and pairs them with heartbeat monitors for the things that fail silently, like cron jobs, queues, and backups that just stop running. Alerts are configurable so you can require consecutive failures before you're paged, instead of getting woken up by a single blip.
The free plan is honestly free: 5 monitors, 5-minute checks, no credit card. It's enough to cover a real site's core URLs, TLS, and domain today, and to see whether the alerting actually fits how your team works before you pay for anything.
Holter watches this for you: outside-in monitors plus dead-man heartbeats for silent failures. Free plan: 5 monitors, 5-minute checks, no credit card.
Create your first monitor — free