Why Website Monitoring Matters Before Something Breaks

There are two ways to learn that your website is down. One is an alert on your phone at 6:40am, followed by a fix before anyone at the office has made coffee. The other is a customer emailing at 11am to say they’ve been trying to place an order since yesterday.

The difference between those two experiences is monitoring, and it is one of the cheapest, most under-used things a business can put in place. Here is what it should cover, roughly in order of value.

1. Is the site up? (from outside)

The basic check: something outside your hosting requests a page every one to five minutes and alerts a person if it fails. Outside matters — a check running on the same server as the site goes down with the site.

Two details separate useful from useless:

• Check for content, not just a status code. A server that has lost its database returns a perfectly healthy HTTP 200 with “Error establishing a database connection” as the page. A cache can serve stale pages after the origin has died. The check should look for a specific string that only appears when the site is genuinely working — a phrase from the footer, for example.
• Alert a phone, not only an inbox. An email alert at 2am is read at 8am. SMS, a push notification, or a phone call for anything that stays down more than a few minutes.

Uptime Kuma (self-hosted, free), UptimeRobot, Better Stack, Pingdom — any of them do this well. The choice matters less than the fact of having one.

2. Is the certificate about to expire?

An expired TLS certificate is a total outage in every browser, and the cause is always the same: renewal was manual, or automatic renewal broke months ago and nobody noticed. Most uptime tools will check certificate expiry and warn two weeks out. Turn it on.

3. Is the domain about to expire?

Same failure, worse recovery. A monitoring check on the domain’s expiry date (or, at minimum, a calendar reminder that goes to more than one person) is cheap insurance against the registrar email going to a former employee.

4. Is the server running out of something?

If you have a VPS or dedicated server, the things that cause “mystery” outages are visible well before they happen:

• Disk usage — alert at 80%, act before 90%. A full disk breaks the database and logins in confusing ways.
• Memory and swap — alert when free memory is consistently low or swap is being used heavily. That is the precursor to the OOM killer taking down MySQL.
• CPU load sustained above the number of cores.
• Services — is MySQL running? Is PHP-FPM? Is the web server?

Netdata, Prometheus with node_exporter, the host’s own metrics, or a simple agent from your uptime provider. The goal is a graph you can look at when the site feels slow and an alert before the ceiling is hit.

5. Did the backup run?

A backup job that stops running fails silently. A check that alerts when no successful backup has completed in the expected window turns silence into a signal. Most backup tools can ping a “dead man’s switch” URL (Healthchecks.io, Cronitor) on success; the service alerts if the ping stops.

6. Did something change that shouldn’t have?

For WordPress: file integrity monitoring that notices when core or plugin files change outside of an update, and a check that alerts when an installed plugin has a newly published vulnerability. Both are early warning of a compromise or of a patch that needs applying today rather than next month.

7. Is email getting through?

A weekly automated test through the site’s contact form, checking that the message arrives. Form and order emails fail quietly and are usually discovered by their absence, which can take weeks.

What not to alert on

Monitoring fails in two directions. Too little and you miss the outage. Too much and every alert is ignored because most of them were noise. The second failure is more common among people who set up monitoring enthusiastically.

Rules that keep alerts meaningful:

• Alert on impact, not on every metric. CPU at 90% for thirty seconds is not an alert. The site being unreachable for three minutes is.
• Require confirmation. Most tools can check from a second location before alerting, which removes false alarms from a single network hiccup.
• Have one place alerts go, and one person (or rotation) who acknowledges them. Alerts sent to a group address are alerts everyone assumes someone else is handling.
• Review monthly. If an alert fired and nobody acted, either it should not exist or the response is broken. Fix one or the other.

The minimum that changes everything

If you do nothing else: one external uptime check with a content match, alerting a phone, plus certificate and domain expiry warnings. That takes twenty minutes to set up, costs nothing or nearly nothing, and means you will never again hear about an outage from a customer.

Server metrics, backup monitoring and integrity checks come next, and are part of what we run for clients under managed IT services. Item 9 on the Website & Infrastructure Health Checklist is this article in one line: external uptime monitoring alerts a human. If you can’t say yes to that today, it is the highest-value hour you can spend on your website this month.