Most teams set up uptime monitoring once, point it at the homepage, and forget about it. That works until the site is "up" but checkout is broken, or email forms silently fail, or the admin panel crawls while marketing pages look fine.
Uptime is not one boolean. It is a stack of things your users care about. Good monitoring matches alerts to real pain, not every blip on a graph.
Homepage checks are a start, not a finish
Pinging / tells you Apache answered. It does not tell you:
- Your database connection is dead
- Contact forms stopped posting
- SSL is expired or serving the wrong certificate
- WooCommerce checkout returns 500 on the payment step
- DNS points at an old server after a migration
Add at least one synthetic check on a critical path. For a brochure site that might be the contact form thank-you page. For a store, hit a lightweight cart or health endpoint if you have one.
What to alert on (and what to log quietly)
Page down from multiple regions. One failed probe from a flaky monitor location is noise. Two or three regions agreeing is worth waking someone up.
SSL expiry inside 14 days. Let's Encrypt renews automatically until it does not. Certificate monitors are cheap insurance.
Response time regression. Alert when median TTFB crosses a threshold you set from your own baseline, not a generic "slow" number from a blog post.
Specific HTTP status on key URLs. 200 on homepage plus 500 on /wp-admin is a common WordPress failure mode after a plugin update.
Log but do not page people for: single 503s during deploys, brief CPU spikes during backup windows, CDN cache misses.
Canadian angle: monitor from where your users are
If your audience is mostly in Alberta and Ontario, a monitor running only from US-East can miss regional routing issues or show green while Canadian users struggle. Mix probe locations: at least one Canadian or North American path that matches your user base, plus one outside your primary region to catch total outages.
We host in Canadian data centres (Edmonton, Beauharnois, Toronto/Cambridge). Monitoring from a single overseas probe has blind spots for latency-sensitive apps even when the server is healthy.
Who gets paged vs who gets an email
Define tiers before something breaks at 2 a.m. on a long weekend:
- P1 (SMS/call): Site unreachable, checkout down, ransomware indicators, certificate expired
- P2 (email/Slack): Degraded performance, non-critical subsystem, disk at 85%
- P3 (daily digest): Trend warnings, backup job took longer than usual
If everything is P1, people ignore alerts. If nothing is P1, real outages sit in an inbox until Monday.
Tools we see work for small teams
You do not need enterprise APM on day one. UptimeRobot, Hetrix, Better Stack, Pingdom, or self-hosted Uptime Kuma all cover the basics. Pair external checks with something on-server: disk space, failed cron, backup exit codes. Your host's control panel often has resource alerts; turn them on.
For WordPress, the health check under Tools is rudimentary but catches PHP version and loopback failures. Plugins can lie; an external HTTP check does not.
Runbooks beat heroic debugging
Each alert should link to three lines: what this means, first thing to check, who to escalate to. "Homepage down" runbook might start with DNS, then server ping, then recent deploys. Without that, on-call becomes guesswork.
Test alerts quarterly. Send a fake page to confirm SMS still works and the right person receives it.
Bottom line
Monitor the workflows that pay your bills, not just the logo on the homepage. Tune alert noise so real failures get attention. Match probe geography to your Canadian users when that is where you serve.
Want help setting up monitoring on Canadian-hosted infrastructure? Talk with Swift Host. We can suggest checks that fit your stack without selling you a dashboard you will never open.
