Downtime alerts: how to get notified by email, SMS or phone when your website goes down

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.

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.

Check how the alerts themselves are billed

Here is the cost detail that catches people out: at several vendors the plan price covers the checks, and the alerts are metered separately. SMS and voice usually run on a credit balance, and a credit is normally consumed per phone number per notification, so paging three people about one incident spends three credits. HetrixTools charges a flat $0.10 per credit beyond its monthly allowance. StatusCake includes 75 SMS credits on Superior and 400 on Business. Pulsetic runs a shared bundle with the same $0.10 overage.

The awkward part is that the month you exceed the allowance is, by definition, the month things were already going badly. If your on-call roster is more than one person, work out your realistic credit burn before you compare monthly prices. We put every vendor's alert billing next to its plan price in the uptime monitoring pricing comparison. Our own answer is to not meter it: SMS, email, Slack and webhook alerts are unmetered on every AlertPing plan.

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.

1. Monitor the real URL a customer hits, including the full path if your app lives at one, not just the bare domain.
2. Set the interval to 30 seconds for anything that matters, so your blind window stays small.
3. Require multi-region confirmation before an alert fires, so a single network blip cannot page you.
4. Put your primary alert on SMS or a phone call, and keep email only as a secondary record.
5. Add Slack or Teams for daytime team visibility, on top of the wake-someone channel, never instead of it.
6. Build an escalation policy so an unacknowledged alert climbs to the next person automatically.
7. Watch the SSL certificate and DNS too, since an expired cert takes the site down just as hard as a crash.
8. 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.

Making a downtime alert email that actually arrives

Email is the channel nearly everyone starts with, and the query people type is usually some version of "downtime alert email". It is a reasonable place to start, as long as you treat it as the written record rather than the thing that wakes you. What breaks it is almost never the monitoring tool. It is delivery.

Automated alert mail has every property a spam filter dislikes: it is machine generated, it is bursty, it often arrives from a domain you have never corresponded with, and the subject line contains words like "down" and "error". So four things are worth doing once, before you need them.

• Allowlist the sender. Add your monitoring vendor's alert address to a safe-sender rule in Google Workspace or Microsoft 365 at the org level, not just in one person's mailbox.
• Send to a distribution alias, not an individual. An alias like alerts@yourdomain survives someone leaving, changing role, or going on vacation with an out of office.
• Do not filter alerts into a folder. A rule that files downtime mail under "Monitoring" is a rule that hides it. If the volume is high enough that you want to file it, the real problem is alert noise, not inbox tidiness.
• Test it from cold. Trigger a real failure and confirm the mail lands in the inbox, on a phone, with a notification, at a time when nobody is expecting it.

Then treat the result honestly. Even a perfectly delivered email is a poor page: phones do not ring for mail at 2am, and the median gap between "email arrived" and "human read it" overnight is hours. Keep the email for the audit trail and the daytime heads-up, and put SMS or a voice call in front of it for anything with money attached.

What are downtime notifications, and how do they differ from monitoring?

Downtime notifications are the outbound messages a monitoring system sends when a check fails: the SMS, the phone call, the Slack post, the email, the webhook into your own systems. Monitoring is the detection half, notification is the delivery half, and they fail independently. A tool can detect an outage perfectly and still be useless because the notification went to a Slack channel nobody has open at midnight.

Worth separating out, because the two get bought as one product and reviewed as one product. When you evaluate a vendor, ask the notification questions separately: which channels are included rather than metered, whether SMS costs credits, whether escalation happens automatically if the first person does not acknowledge, and whether recovery notifications are sent as well as failure ones. A tool that texts you when the site breaks and never tells you it came back leaves you refreshing a dashboard at 4am.

On our side, SMS, email, Slack and webhook are on every plan with no credit packs to run dry, and the full breakdown of what each channel is good for is on the website down alerts page.

How do I get my site to notify me when it is down?

Your site cannot notify you when it is down, and that is the whole trap in the question. Anything running on the same server, whether that is a WordPress plugin, a cron job, a health-check script or a log watcher, dies with the server. You need something outside it to do the noticing, and then you configure that outside thing to notify you. Concretely:

1. Create an external HTTP check against your public URL, not an internal IP.
2. Set the interval to 30 or 60 seconds depending on how much downtime you can absorb.
3. Require confirmation from a second region before the failure counts, so one flaky network path does not page anyone.
4. Attach SMS or a phone call as the primary notification, with email as the record.
5. Add an escalation step so the alert moves on if nobody acknowledges it in five minutes.

That is five minutes of setup and it is the difference between finding out from a monitor and finding out from a customer.

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.

What is a downtime alert?

A downtime alert is a message sent automatically when a monitoring system finds that a website, API or server stopped responding correctly. It names what failed, what the error was, and when it started. A useful one also arrives on a channel that interrupts a person, and is followed by a recovery message when the service comes back.

Can I get downtime alerts by text message?

Yes, and SMS is the right default for anything revenue-affecting because it triggers a phone notification without needing an app installed or a data connection. Check how the vendor bills it: several meter SMS as credits consumed per recipient per notification, so alerting four people costs four credits. Ours are unmetered on every plan.

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.