What “down” actually means
Your homepage can look fine on your phone at lunch and still be unreachable for customers in another city. Hosting panels “go green.” DNS still resolves. The failure is quiet until someone tweets a screenshot—or until Monday when the contact form is empty and you wonder why. For small businesses, uptime is not a dashboard hobby. It is naming a person, a phone, and a 15-minute response path before the outage starts.
This is an operator checklist TwoQM recommends—not a vendor bake-off.
Uptime tools disagree on labels. Align your team on three practical states:
Down — The URL customers use returns errors, times out, or never loads for checks from more than one location.
Degraded — The site loads slowly, mixed content breaks forms, checkout or booking fails while the homepage still paints.
False alarm — One probe fails (local ISP blip, single region, blocked bot UA) while real browsers still work.
If you treat every red blip like a fire drill, people mute alerts. If you wait for a customer complaint, you already lost an hour of leads.
Pick a probe that matches how customers arrive
Start with the public URL people type or click from Google, ads, and email signatures—usually https://www.example.com or the apex after your chosen redirect.
Minimum probe setup:
HTTPS GET on the marketing homepage (and, if you take payments or bookings, one critical path page).
Interval — Every 1–5 minutes for customer-facing sites; never “once an hour” if leads matter same-day.
Locations — At least two regions. One probe can lie; two agreeing is actionable.
Timeout — Short enough to catch hangs (for example 10–15 seconds), not so aggressive that every cold start pages you.
Keyword or status check — Confirm HTTP 200 and a short unique string that proves your app rendered (footer copyright year, “Contact,” product name)—not only that a reverse proxy answered.
Do not monitor only the host’s “server status” page. Customers hit your hostname through DNS, CDN, WAF, and origin. Probe the same path they use.
Name owners before you turn alerts on
Write three lines in a shared note the whole team can find:
Primary on-call — Name, mobile, hours covered.
Backup — Who gets elevated if primary does not acknowledge in 10–15 minutes.
Escalation — Host support ticket path, DNS registrar login owner, CDN/WAF owner if those are separate.
Rotate if people leave. An alert that texts a former employee is decoration.
Also decide quiet hours. Nights and weekends still need a reachable backup if the site takes bookings or forms that drive next-day revenue. “We’ll see it in the morning” is a business choice—make it explicit.
Alert channels that people actually answer
Email-only uptime mail sits unread beside newsletters. Prefer a stack that pages a human:
SMS or voice for confirmed down (after a short confirm window).
Chat push (Slack/Teams) for degraded and for the acknowledge thread.
Ticket only as the audit trail—not the first ring.
Require an acknowledge action: someone taps “I’m looking” so the backup is not woken twice for the same incident. If nobody acknowledges in 10–15 minutes, auto-page the backup.
Confirm before you wake the whole company
Good monitors confirm:
Fail once.
Retry from a second location (or wait one more interval).
Then page.
That filter cuts most single-region flakes. Keep a short runbook link in the alert body: check status page, open the URL in an Incognito window on cellular data, note HTTP status, screenshot, then open the host ticket with hostname and timestamp.
What to check in the first 15 minutes
When the page hits:
Reproduce — Phone cellular + one desktop Incognito. Note exact URL and time (America/Chicago for your ops log).
Scope — Homepage only? Forms? Checkout? Mail? Staging vs production mix-up?
DNS — Does the name still resolve to the expected target? Recent nameserver or record edits?
CDN / WAF — Edge challenge pages, IP blocks, or mis-set “under attack” modes that block real users.
Origin / host panel — Disk full, stopped PHP/Node, expired billing, maintenance flag, SSL interstitial (separate from “server up”).
Deploy window — Did someone push, restore a backup, or flip DNS in the last hour?
Log what you tried. The second page of an outage is always worse without notes.
After restore: close the loop
Do not silence the monitor and walk away.
Confirm the probe is green from both locations for several intervals.
Smoke-test contact form, booking, or checkout if those are money paths.
Write a three-line postmortem: trigger, fix, prevention (disk alert, billing card, deploy checklist).
Update the on-call roster if the wrong person got the first page.
Same-week checklist
Homepage HTTPS probe every 1–5 minutes from ≥2 locations
Keyword/status check proves your app, not only the proxy
Primary + backup named with working mobile numbers
SMS/voice for confirmed down; chat for acknowledge thread
10–15 minute escalate-to-backup if no acknowledge
Runbook link inside the alert text
Post-restore smoke test for forms/checkout
Quiet-hours policy written down (even if the answer is “page anyway”)
Uptime tooling is cheap compared to a silent weekend of lost leads. The hard part is naming who wakes up—and making sure that person still works here.