Uptime Monitoring and Alerts: Know Before Your Customers Do

The average undetected outage at a small business is embarrassingly long: the first report usually arrives as an angry post on social media, hours after the site went down. Monitoring fixes the detection problem cheaply. A useful setup has exactly three parts, and missing any one of them is why monitoring systems end up ignored.

The three parts

• Periodic checks. Beyond plain HTTP status, check what actually matters to your service: a TCP port for a mail or game server, ping for raw reachability, and — often the most valuable — a keyword check that fetches the page and confirms expected text is present. A page that returns 200 with a PHP error dump is "up" by status code and completely broken in reality; the keyword check catches it.
• Flap-aware state transitions. A one-second blip during a restart should not page anyone. Monitoring systems only declare a state change after N consecutive failed attempts — for example, three failures at one-minute intervals means "down", and a matching success streak means "recovered". That threshold is the difference between alerts you trust and alerts you mute after a week. Recovery notifications matter just as much as failure alerts: at 3 a.m. they tell you to go back to sleep.
• Multi-channel alerts. Email alone is too slow for some teams; Telegram or a webhook to your chat tool reaches a phone in seconds. Route alerts to whichever channel someone actually watches, and keep delivery logs so you can prove a notification was sent.

Check intervals and alert fatigue

Check frequency is a trade-off: every 60 seconds catches incidents fast but multiplies false alarms from transient blips; every 5 minutes is calmer but stretches the worst-case detection time. A practical compromise is 1–2 minute checks with the flap threshold described above, and per-channel severity — page someone at night only for the monitors that end the business, and let everything else wait for morning email. Escalation helps too: if an alert is not acknowledged within 10 minutes, send it to the next channel. The monitoring that survives is the one whose alerts are always worth reading.

What to monitor beyond uptime

Two expiry clocks silently kill sites: the TLS certificate and the domain registration. Both fail "gracefully" — the site works today and shows a full-page browser warning or a parked page tomorrow. Certificate expiry is a direct check against port 443: if the certificate has fewer than 14 days left, alert. Domain expiry can be tracked through WHOIS data with warnings at 30, 14 and 7 days. Automation occasionally breaks — an expired API token or a changed DNS record can silently stop renewals — so the expiry alarm is the safety net underneath your automation.

The WhoDNS monitoring section implements all of this: create HTTP, keyword, port, ping, certificate and domain-expiry monitors, attach email, Telegram or webhook alerts with state-transition logic, and publish a public status page if you want the same data visible to customers. Start with your homepage, your payment flow and your certificate clock — those three monitors catch most real incidents.

🔗 Related tool: Set up uptime monitors with alerts