Tutorial · migration-hosting · Published 2026-08-15 · 3 min read
Setting up uptime monitoring for a website
Setting up uptime monitoring: external HTTP checks, regions, alert settings, status pages and the workflow when an alert fires.
The one check that changes everything
An uptime monitor is an external service (in another location from your host) that repeatedly requests your site and alerts you when it fails. "External" is the whole point: a check from your host's own panel says nothing about what the world sees, and the website not loading problem usually shows up first in an external probe.
Step 1: register an external monitor
Pick a monitoring service (most provide a free tier for a handful of URLs) and add:
- The URL to check:
https://www.example.com/(the root, or a lightweight endpoint that returns 200 quickly). - The method (GET by default), the expected status (200), and a keyword check where you want proof the page rendered (not just "any 200"), e.g. text in the
<title>. - Check interval: 1 minute for the main site, 5 minutes is acceptable for a low-traffic brochure. The shorter the interval, the quicker the alert and the noisier the false-positive risk.
Step 2: notification and throttle
- Add alerts to at least two channels (email and push/mobile are the standard pair) and confirm the test-message flow works before trusting it; a monitor nobody reads is a placebo.
- Set the alert threshold: most services alert after 2 to 3 consecutive failed checks, which filters a single hiccup while still catching a real outage.
- Whitelist maintenance windows so scheduled deployments do not page you at 2am. The staging to live article reminds you to include the launch window.
Step 3: use the downtime report as a record
A monitor is also an audit: the reports it keeps let you prove uptime (customers and search crawlers both hate unannounced downtime) and find the pattern of short blips. Log each alert with the browser check: was it a full outage, an edge 5xx, or a slow page? The 5xx family article helps separate server failure from a misstep in deployment.
Step 4: turn the alert into a ritual
When an alert fires, the fixed routine shortens the outage:
- Confirm the site is actually down from your own browser (not just the monitor's region).
- Check the obvious first: the domain/DNS, the certificate, the host panel, and the server disk if the host alerted.
- Fix, then watch the health check turn green and the log to confirm the recovery.
The parts most monitoring setups forget
- Transaction checks (buy flow, form submit, login) matter for commerce: a site that loads but whose checkout errors remains "up" in a status-page sense while being dead commercially. Add a scripted synthetic transaction for critical flows.
- The SSL expiry check is cheap and separate; an expired cert can break a site while status pages run green.
- Page speed outliers (the monitor recording load time over a threshold) often precede crashes. The page speed insights article lists the fixes.
Uptime monitoring pairs with the hosting panel guide, because the panel is usually what you reach for when the first alert fires.