Checklist
Website Health Monitoring Checklist
What to check
Start with the homepage, login page, checkout or booking flow, and any customer-facing URL that directly affects leads or revenue. Don't stop at the homepage — a broken checkout page costs more than a broken homepage, but a homepage-only check would miss it entirely.
When to check
Run a check before launches, after changes, during client reviews, and whenever a page feels slow or uncertain. Match the frequency to risk: a low-traffic brochure site might only need a monthly check, while an ecommerce checkout flow deserves a check before every sale or promotion.
What signals to watch
Review reachability, returned status codes, response time, SSL warnings, and any unavailable domain or provider-based signals. A 200 status with a slow response time is a different problem than a 500 error, and both are different from a certificate warning — treat them as distinct signals, not one pass/fail result.
What to do when a site looks down
Confirm the result from a second source if possible, check what changed recently (a deploy, a plugin update, a DNS change), review hosting or DNS status pages, and tell the responsible owner what needs attention with a specific, timestamped description of what was observed.
Building a repeatable cadence
A checklist run once at launch and never again isn't a monitoring practice — it's a one-time audit. Pick a cadence (weekly for high-risk sites, monthly for lower-risk ones) and stick to it, so a check becomes a routine rather than something that only happens after a complaint.
Documenting what you find
Even a simple log — site, date checked, result, any action taken — turns individual checks into a record you can point to later, whether that's proving a maintenance retainer's value to a client or spotting a site that's degraded gradually over several checks.
Frequently asked questions
How often should I run an uptime check?
It depends on the site's risk level. A low-traffic brochure site is often fine with a monthly check, while an ecommerce or SaaS signup flow benefits from more frequent checks, especially around launches, promotions, or after any recent change.
Is a 200 status code enough to confirm a site is healthy?
No. A 200 status only confirms the server responded successfully — it doesn't rule out a slow response time, an SSL warning, or a redirect landing somewhere unexpected. Each of those is worth checking as its own signal.
What should I do first when a check shows a site is down?
Confirm the result isn't a fluke (a second check from a different network helps), check what changed recently, and review hosting or DNS status before assuming the cause. Document what you observed before escalating, since a specific description is more useful than a vague "it's down."