To monitor website uptime: choose check types that match real failure modes, set a 30-second interval, require multi-region confirmation, wire alerts to channels people actually see, and publish a status page. Five decisions, about 15 minutes of setup. Here is each step, with the math behind it.
Step 1. Choose check types that cover real failure modes
"The site is down" has many causes, and a plain homepage check only catches some of them. Cover the ways your service actually fails:
- HTTP/HTTPS checks on your homepage and your money paths (checkout, login, signup), with keyword assertions so a pretty error page does not count as "up". For endpoints, an API monitoring tool with JSON assertions catches contracts that break while still returning 200.
- SSL certificate checks. An expired certificate takes you offline for every browser at once. SSL certificate monitoring should warn at 30, 14, 7 and 1 days before expiry.
- Port checks for the services behind the site: SMTP, databases, custom TCP/UDP. Port monitoring catches the mail server that died on Friday before Monday's password-reset complaints.
- Cron heartbeats for scheduled jobs. Backups and billing runs fail silently; a cron job monitoring heartbeat alerts you when a job that should have pinged did not.
A typical small production setup is 5 to 10 monitors: two or three HTTP checks, SSL on each domain, one or two ports, and heartbeats on the jobs you cannot afford to lose. Wondering whether you also need scripted browser journeys on top of this, the comparison of synthetic monitoring vs uptime monitoring draws the line between the two.
Step 2. Set the check interval (the 30-second vs 5-minute math)
Your interval is your worst-case blindness. With 5-minute checks, an outage that starts right after a green probe runs 4 minutes 59 seconds before monitoring even looks again; average detection is 2.5 minutes, plus confirmation. With 30-second checks the worst case is 30 seconds and the average is 15.
Put that against your downtime budget. At 99.9% you get 43 minutes 50 seconds a month; a 5-minute interval can spend a quarter of that budget on detection alone across a handful of incidents. At 99.95% or better, 5-minute checks cannot even verify the number you are claiming, because whole outages fit between two probes. Short intervals are also what make your measured uptime percentage honest, as covered in what is a good uptime percentage.
Step 3. Require multi-region confirmation before anything pages you
Frequent checks from a single location create a new problem: false alarms. At 30-second intervals a monitor probes 2,880 times a day. Even if transient network noise between one vantage point and your server affects just 0.05% of probes, that is about 1.4 false failures every day, over 40 bogus pages a month. That is how teams learn to ignore their own alerts.
The fix is confirmation: when one region sees a failure, a second region re-probes immediately, and nothing fires until both agree. The odds of independent network paths from US East and EU Central both producing the same false failure within seconds are tiny, so second-region confirmation keeps the 30-second sensitivity while removing the noise. This is the core of how uptime monitoring works at AlertPing: single blips never page anyone.
Step 4. Wire alert channels and escalation
Detection is worthless if the alert dies in a muted channel. Route by time and severity: Slack or email for daytime and low-stakes checks, SMS for anything that wakes someone, webhooks to feed your own tooling. Then add an escalation chain: if the on-call engineer does not acknowledge within 5 minutes, the backup is paged; after 10, the team lead. An outage that pages one phone that is on airplane mode is still an unwatched outage. Every AlertPing plan includes SMS downtime alerts alongside email, Slack and webhooks, with escalation chains and on-call hours on Team plans and up.
One warning from every team that has run on-call for a while: protect the SMS channel. If low-stakes checks page phones at night, people mute the channel within a month and the one alert that mattered dies in silence. Reserve SMS for confirmed, customer-facing outages and let everything else land in Slack, and the pager keeps its authority.
Step 5. Publish a status page
The last step is for your customers. A public status page that updates automatically from your checks answers "is it just me?" before it becomes a support ticket, and a subscriber list emails customers updates so you are the one telling them, not the other way around. During a real incident it becomes your single source of truth; the templates in our incident communication guide slot straight into it.
Which uptime monitoring tool?
Honestly: any serious tool beats no monitoring, and the tools differ most on interval, confirmation and alerting. UptimeRobot is a capable entry point, but its lower tiers check at multi-minute intervals and SMS costs extra; Pingdom is mature and deep, with per-monitor pricing that grows quickly as you add checks. AlertPing's model is 30-second checks, second-region confirmation and SMS included on every plan at a flat price. The factual side-by-side tables are on the UptimeRobot alternative and Pingdom alternative pages; check the rows that matter to you before choosing.
alertping
All five steps, set up in about 15 minutes
Add a URL and the first check runs within a minute: 30-second probes, second-region confirmation, SMS included, status page hosted. No agent to install.
That is the whole system: the right checks, a 30-second interval, multi-region confirmation, alerts that reach a human, and a status page that talks to customers. Build it once and downtime stops being something you find out about from Twitter.