To get alerted when your website goes down, put an external monitor outside your own network that requests the site every 30 seconds, confirms the failure from a second location to kill false alarms, and then pushes the alert by SMS or phone call, not just email. Email alone fails at night and can sit in spam. The reliable setup is: outside check, second-location confirmation, and a channel that actually wakes a person.
That is the whole answer in three moving parts. Everything below is why each part matters, and what to configure so the alert reaches a human in seconds instead of showing up in a support ticket the next morning. The failure people keep hitting is not that they lack a monitor. It is that the monitor exists but the alert never woke anyone, or it fired ten times for a blip that was never real.
Your own server cannot tell you it is down
This is the part that trips up teams who think a log line or a cron job on the box is enough. If the machine hosting your site crashes, its network drops, or the data center loses power, the thing you would rely on to send the alert is the exact thing that just died. A monitor living inside your own infrastructure goes dark at the same moment the site does, and dark monitors send nothing.
An external check runs somewhere else entirely. It makes a request to your public URL the same way a real visitor would, over the open internet, and it judges the site by what comes back: the HTTP status, whether the page loaded, how long it took. Because it lives outside your network, it keeps working when your network does not. It sees the outage from the customer's side, which is the only side that pays you.
This also catches problems your internal tooling never sees: an expired DNS record, a firewall rule that started blocking outside traffic, a CDN misconfiguration, a lapsed SSL certificate. From inside the building everything looks fine. From the outside, nobody can reach you. Only an external check tells you what your visitors are actually experiencing.
Rank your channels by whether they wake someone at 3am
A downtime alert is only worth as much as the channel it travels on. Most outages that cost real money happen off-hours, when nobody is staring at a dashboard. So the honest question for any alert channel is not "will it deliver" but "will it wake the person who can fix this." Ranked by that test, the channels sort out cleanly.
| Channel | Wakes you at 3am? | Caveat |
|---|---|---|
| Phone call | Yes, hardest to ignore | Overkill for low-severity blips; save it for real escalation. |
| SMS / text | Yes, most phones alert on it | Depends on carrier delivery; keep messages short and clear. |
| Push / mobile app | Usually, if notifications are on | Silenced by Do Not Disturb unless marked time-sensitive. |
| Slack / Teams | Only if someone is watching | Great for daytime team visibility, useless while everyone sleeps. |
| Webhook | Only if it feeds something that pages | A webhook is plumbing, not a person; it needs a destination that alerts. |
| Rarely | No sound at night, and it can land in spam or promotions. |
Email is the one people over-trust. It is fine as a paper trail and fine for the daytime, but as a wake-someone-up channel it fails twice over. First, a phone on the nightstand does not ring for email. Second, automated alert mail has a real habit of getting filtered, and whether it reaches the inbox at all depends on deliverability factors that are easy to get wrong, so the one message you most needed can quietly land in spam. Use email as a record, not as your primary alarm. Set up proper downtime alerts on SMS or a phone call for anything that genuinely cannot wait until morning.
Why a 30-second interval beats a 5-minute one
The check interval is how often the monitor tests your site, and it sets the ceiling on how fast you can possibly find out about an outage. A five-minute interval means the site can be down for nearly five minutes before the monitor even looks. A 30-second interval caps that blind window at half a minute. On a busy store or an API that other systems depend on, the difference between those two windows is a lot of failed checkouts and a lot of angry retries.
Shorter intervals also make confirmation faster. When a monitor needs a second opinion before it pages you (more on that next), it runs another check to get one. At 30 seconds those extra checks happen quickly, so a real outage is confirmed and sent in well under a minute. At five minutes, the confirmation step alone can add minutes on top of an already slow window.
Confirm from a second region to kill false alarms
A single check from a single location lies to you sometimes. A brief network hiccup between the monitor and your server, a momentary routing problem, a one-off timeout: none of these mean your site is actually down, but a naive monitor will page you for all of them. Do that a few times and people start ignoring the alerts, which is worse than having no monitor at all, because now the real outage gets ignored too.
The fix is confirmation. When the first check fails, a good monitor immediately re-tests from a different region before it decides anything. If the second location also fails, the outage is real and you get paged. If the second location loads the site fine, the first failure was a network blip on one path and you hear nothing. Checking from three regions and requiring agreement means the alert you receive is one you can trust, and trusted alerts are the only ones people keep responding to.
This is the single biggest reason picky teams shop around. If you are comparing options, the roundup of the best uptime monitoring tools is a good place to see how different services handle multi-location confirmation, since not all of them do.
Decide who gets paged, and what happens if they miss it
Detection is half the job. The other half is making sure the alert lands on a person who can act, and that it does not die in one person's silenced phone. That is escalation: a defined order of who gets notified, and a rule for what happens when the first person does not respond.
A workable policy for a small team looks like this. The site fails and stays failed through confirmation, so the on-call engineer gets an SMS. If nobody acknowledges within a few minutes, the alert escalates to a phone call, then to a second person, then to the team lead. Nobody has to be awake and watching, because the policy keeps climbing until someone responds. For customer visibility during all this, a public status page lets people check whether you already know, which cuts the flood of "is it just me" tickets while you work.
What to actually configure
Here is the concrete checklist. It takes about ten minutes to set up and it is the difference between a monitor that pages you and a monitor that decorates a dashboard.
- Monitor the real URL a customer hits, including the full path if your app lives at one, not just the bare domain.
- Set the interval to 30 seconds for anything that matters, so your blind window stays small.
- Require multi-region confirmation before an alert fires, so a single network blip cannot page you.
- Put your primary alert on SMS or a phone call, and keep email only as a secondary record.
- Add Slack or Teams for daytime team visibility, on top of the wake-someone channel, never instead of it.
- Build an escalation policy so an unacknowledged alert climbs to the next person automatically.
- Watch the SSL certificate and DNS too, since an expired cert takes the site down just as hard as a crash.
- Test it by breaking it. Point a monitor at a URL you can take offline, and confirm the alert actually reaches your phone.
That last step is the one everyone skips and the one that matters most. An untested alert chain is a guess. The only way to know the SMS arrives, the escalation climbs, and the confirmation logic behaves is to cause a failure on purpose and watch the whole thing run once.
How do I get notified when my website goes down?
Use an external uptime monitor that checks your public URL on a short interval from outside your network. When a check fails, it confirms from a second location, then sends an SMS or phone call to whoever is on call. Do not rely on your own server or on email alone to raise the alarm.
Is email enough for downtime notifications?
No, not on its own. Email works as a written record and for daytime awareness, but phones do not ring for it at night and automated alert mail can be filtered into spam. Use SMS or a phone call as your primary downtime notification, and treat email as the backup log.
How fast will I find out my site is down?
That depends on your check interval plus confirmation time. With a 30-second interval and multi-region confirmation, a real outage is usually detected and sent within about a minute. A five-minute interval can leave your site down for several minutes before the monitor even looks, which is why short intervals matter.
Can I get a phone call, not just an app notification?
Yes. A phone call is the hardest alert to sleep through, which is why it belongs at the top of an escalation policy. A common setup sends an SMS first, then escalates to a voice call if nobody acknowledges within a few minutes, so a missed text does not become a missed outage.
The short version
An alert only works if it reaches a person. Put the check outside your own network so it survives the outage, run it every 30 seconds so the blind window stays small, confirm from a second region so blips do not cry wolf, and send the real alert by SMS or phone call rather than trusting email to wake anyone. Then wire up an escalation policy and test the whole chain by breaking something on purpose. Do that once, and the next time your site goes down, you will know before your customers do.