On this page
  1. How do I set up a down-alert in 10 minutes?
  2. How do I avoid false alarms?
  3. How do I verify the alert actually works?
  4. Where AI coding assistants get this wrong
  5. Checklist
  6. FAQ
    1. What’s the cheapest way to get down-alerts?
    2. Should I monitor the homepage or a health endpoint?
  7. Related topics
  8. Sources
tutorial

How to Get Alerted When Your Site Goes Down

Set up down-alerts for your site in 10 minutes: an uptime check, the right alert channel, and a test that the alert actually fires.

Quick answer

  • The fastest setup is an external uptime monitor (UptimeRobot, Better Stack, or similar) with alerts sent to your phone.
  • Configure the check interval to match how quickly you’d want to know: 1 minute for production.
  • Always test that the alert fires — an untested alert is a promise nobody verified.

How do I set up a down-alert in 10 minutes?

Create a free account at an uptime monitoring service, add your URL as a monitor, set the interval (1 minute for anything real), choose which locations to check from (more is better), and pick an alert channel you actually check — mobile push or SMS beats email. That’s the whole setup. The service now pages you whenever the site stops responding.

# curl your site exactly the way a monitor would, from outside
curl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" https://yourdomain.com
# 200 in 0.42s   <- what a healthy response looks like

How do I avoid false alarms?

A single failed check should not page you — transient blips happen during deploys and network hiccups. Most services let you require 2-3 consecutive failures before alerting, and that’s the right default. Also point the check at a URL that represents real availability: your homepage or an API health endpoint, not a page that could be cached or redirected.

How do I verify the alert actually works?

Test it end to end: temporarily point the monitor at a URL that doesn’t exist, or stop your server, and confirm the alert arrives. Also verify the recovery notification — you want to know when it’s back up, not just when it’s down. An alerting setup you’ve never seen fire is configuration, not protection; testing it once takes two minutes and confirms the whole chain: check, retry threshold, channel, your phone.

Where this bites vibecoders

The classic story: a vibecoder’s side project goes down on a Friday, and the first person to notice is a user on Monday. The AI assistant that deployed the app never suggested monitoring, and ‘the dashboard looked fine’ because nothing was configured to look. Ten minutes of setup converts ‘users discover outages’ into ‘you get a notification and fix it before anyone notices’.

Where AI coding assistants get this wrong

  • Adding monitoring configuration but no alert channel, so incidents are logged and nobody is told.
  • Alerting to email when the team’s email is checked twice a day.
  • Setting a 60-second alert threshold on a check that runs every 5 minutes, creating false alerts.
  • Never testing the alert, so the first real outage reveals the phone number was wrong.

Checklist

  • Create an uptime monitor pointed at your real URL, 1-minute interval, multiple locations.
  • Require 2-3 consecutive failures before alerting.
  • Send alerts to a channel you check immediately: push or SMS.
  • Test the alert fires by taking the site down briefly, then confirm recovery alerts too.

FAQ

What’s the cheapest way to get down-alerts?

Free tiers of UptimeRobot, Better Stack, or cron-job.org cover a small site: one-minute checks and push/email alerts at no cost. You only pay when you need more monitors, sub-minute checks, or team features.

Should I monitor the homepage or a health endpoint?

Both, if you can. The homepage catches ‘site is unreachable’ from a user’s perspective; a health endpoint catches ‘site is up but the database is dead’. If you pick one, make it the page users actually hit.

Sources

Share: