Online is not the same as working
The simplest website monitor requests a page and checks whether the server responds. If it gets a successful status code, it marks the site as up.
That check can stay green while your contact form fails, a redirect sends people to the wrong place, a certificate is about to expire, a browser security policy disappears, or an important page is replaced with something unexpected. The server answered. That doesn't mean the website did its job.
Uptime is worth measuring. It is just the first question.
Check the pages people rely on
Start with the few things the public comes to your site to do. For a membership association, that may be registration, document access, and the contact form. For a public body, meeting notices and service instructions. For an advocacy organization, an action page that has to accept submissions before a deadline.
You don't need to test every path through the site. Cover the small number of pages and features whose failure would cause immediate harm to your operations.
Watch configuration that can change quietly
Some failures happen in the site's configuration instead of on a page. Redirect rules move. A certificate renews incorrectly. A deployment drops a security header. A content security policy gets weaker, or starts blocking a service the site needs.
You won't see any of this while editing pages, which is why it belongs in recurring checks. A useful monitor records what each setting should be and tells you when it changes.
- HTTPS certificate validity and expiration.
- Canonical host and redirect behavior.
- Security headers and browser policies.
- Expected page titles, content markers, and response types.
- Performance changes large enough to affect visitors.
- Important forms or integrations that can be tested safely.
Every alert needs an owner
A mailbox full of alerts doesn't mean the website is managed. Each thing you monitor needs an owner and a plan for what happens next.
The record should say what changed, when it was first seen, which pages are affected, whether it happened again, and what should happen next. Your web team should know when to look at the application, when to call the host, and when the organization has to make a content or policy decision.
What to ask for in a monitoring report
You don't need a dashboard of raw requests. A useful report separates current problems from ones that have recovered, shows which service is affected, includes the evidence, and names the next step.
Ask what the system checks, how often, what it deliberately leaves out, who gets the alerts, and what happens after one arrives. If the answer ends at sending a notification, you have bought detection without a response.
Leland Fiegel