Server Down Alert: Phone Call When Your Server Is Down

How a server down alert reaches you

A server down alert comes from an external monitor that sends an HTTP request to your server every 60 seconds and treats a refused connection, a timeout, a DNS failure or an unexpected status code as down. TrackDowntime rechecks timeouts before it opens an incident, then places an automated phone call and sends an SMS to every number on the endpoint, repeating on a fixed schedule until the server answers normally. Recovery is confirmed by SMS and email.

60s

Between checks on Professional and Enterprise

15

Alert rounds in the first 96 hours of an outage that nobody fixes

5 to 60s

Timeout you set per endpoint before a slow answer counts as down

What a server down alert has to do at 3am

Every server dies eventually, and the alert is the part that decides whether it costs you ten minutes or ten hours. These are the behaviors that separate an alert you can rely on from an email you read over breakfast.

It checks from outside your network

A monitoring script on the same host, or in the same data center, stops when the server stops. The check has to come from somewhere else, because the most common way a server goes down is the whole machine, the network in front of it or the provider's region going quiet at once. TrackDowntime runs the check from its own infrastructure, so a dead server cannot silence its own alarm.

It calls, not just emails

Email is where outage alerts go to wait until morning. On Professional and Enterprise the first alert round places an automated voice call and sends an SMS to the numbers on the endpoint. A call is the one notification most people have not trained themselves to sleep through, which is the point of paying for it.

It calls everyone on the list

Put the on call engineer, a backup and the founder in the same field, separated by commas. Every number gets the call and the text on every round. Nobody has to forward anything, and a phone left on silent in another room does not decide how long the outage runs.

It keeps going until the server is back

Alerts repeat at 0, 5, 10, 15, 20, 30, 40, 50 and 60 minutes, then at 2, 4, 8, 24, 48 and 96 hours while the incident is still open. A call that went to voicemail is followed by another one five minutes later. The schedule stops the moment a check succeeds.

It does not wake you for a blip

A single timeout is often a network hiccup rather than a dead server. Timeouts are rechecked twice, five seconds apart, and DNS timeouts three times, ten seconds apart, before an incident opens. A wrong status code, such as a 502 from the load balancer, opens the incident on the first check because it is a clear answer.

It tells you when it is over

When the server answers normally again, the incident closes and a recovery SMS and email go out, so the person who was woken up learns it is fixed on the same channel. The incident is stored with its start, end and measured duration, and the history can be exported to CSV for a post mortem or a hosting credit claim.

Setting up a server down alert in about five minutes

Step 1

Pick the URL that proves the server is alive

Use a health check route such as /health or /status if your application has one, or the public URL the server exists to serve. A health route that queries the database and returns 503 when it cannot is better than the homepage, because it fails when the server is up but useless.

Step 2

Set the expected status and timeout

Leave 200 as the expected code for most routes, or set the one your health check really returns. Choose a timeout a user would tolerate, usually 10 to 15 seconds, and add custom headers if the endpoint needs a token.

Step 3

Add every phone number that should ring

Enter the numbers in international format, separated by commas: the person on call, a backup and anyone who has to know about an outage. Tick email as well so the incident is also in an inbox for later.

Step 4

Save and let the first check run

Monitoring starts on the next check, 60 seconds later on Professional. The dashboard shows each check's status code and response time, so you can confirm the endpoint is answering the way you expect before you need it at night.

What is the best way to monitor and get alert when a server goes down?

The most reliable approach is an external HTTP monitor that checks a health endpoint on your server every 60 seconds and alerts by phone call, not only email. External matters because a check running on the server, or inside the same network, disappears with it. Phone matters because most outages that do real damage happen when nobody is looking at a screen.

Plenty of teams already run Zabbix, Nagios, Prometheus or a cloud provider's alarms, and those are good at the inside view: CPU, memory, disk, process counts. They answer a different question. If the monitoring server shares a rack, a region or an account with the machine it watches, a network or provider failure takes both down together, and the alert that should have fired never leaves. An outside check is the second opinion that still works when everything inside is dark.

The practical setup most small teams end up with is both. Keep the internal metrics for diagnosis and add one external check per public service that is allowed to phone someone. That external check is what TrackDowntime does.

How to get a server down alert for more than a web page

TrackDowntime checks over HTTP and HTTPS. It does not send ICMP ping, probe raw TCP ports or install an agent on the machine, and it is honest to say so before you buy. For a web server, an application server or an API, HTTP is actually the better signal, because a server can answer ping perfectly well while the application on it returns errors to every visitor.

To make an HTTP check tell you about the whole server, give it something worth checking. A health check route is a small URL in your application, often /health or /status, that tests what the service needs and returns 200 when everything works and 503 when it does not. A useful one:

runs a trivial database query, so a dead or full database fails the check
confirms the cache or queue connection is open
checks free disk space against a floor, so a full disk alerts before it corrupts anything
returns quickly, well inside the timeout, and does no heavy work

Point the monitor at that route and a server down alert now also covers the failures that leave the web process technically running. If the route needs a secret token, add it as a custom header on the endpoint so the public cannot call it.

How can I generate a server down alert only after the server is down more than 5 minutes?

You usually should not wait five minutes, and you rarely need to. The reason people ask for a delay is false alarms: a monitor that phones you for every half second of packet loss gets muted within a week. The better fix is confirmation, not delay.

TrackDowntime confirms before it alerts. A timeout is retried twice, five seconds apart, and a DNS timeout three times, ten seconds apart, so a passing network blip clears itself before anyone is called. A definite error such as a 500 or a 502 alerts on the first check, because the server has already told you it is broken. The result is an alert within roughly a minute of a real failure and very few calls for nothing.

If a particular endpoint genuinely does not justify waking anyone, the answer is a different plan for that endpoint rather than a delay on the one that does: put internal tools on a 5 minute interval with email only, and keep the phone for the services customers pay for.

Why a server down notification by email is not enough

Email alerts assume someone is watching an inbox, and at 2am on a Saturday nobody is. Mail clients batch notifications, phones hold them silently overnight, and the alert address is often a shared mailbox that three people each assume one of the others checks. The outage gets found by a customer instead.

SMS is better, and the phone call is better again, because a ringing phone is the one interruption people still respond to half asleep. The cost difference is the reason many teams stay on email: vendors that bill SMS and voice as credits make every alert round a small charge, and a flapping server can burn through a month's allowance in a night. TrackDowntime includes calls and texts in the Professional and Enterprise plans instead of metering them, so there is no reason to route the important endpoint to email to save money.

If your current provider is Pingdom, which sends SMS against a monthly credit bundle and has no voice call channel, we compared the numbers in Pingdom SMS alerts cost and alternatives.

Who sets up server down alerts, and on what

SaaS teams without a pager rotation

Two or three engineers, no incident management tool yet, and a production API that customers depend on. One health endpoint per service, every engineer's number on the alert, and a clear record of each outage for the status update.

Agencies hosting client servers

The VPS or dedicated servers the agency manages for clients, each on its own endpoint. The agency hears about the outage and starts fixing it before the client picks up the phone to complain.

Ecommerce on its own server

Stores that left shared hosting for a VPS and now own the uptime. The checkout and the payment callback URL are checked separately, because either one failing stops revenue while the homepage still loads from cache.

Internal line of business apps

The order system, the booking backend or the customer portal a business runs on its own server. Staff notice the failure only when the working day starts, which is exactly the delay an external alert removes.

Game, media and community servers

Servers with a web front end or status API where users leave for a competitor within minutes of an outage. The alert goes to whoever holds the keys, not to a forum thread.

Freelance sysadmins and MSPs

Many small servers across different clients, each with its own contact numbers. Unlimited endpoints on Enterprise keep the whole book of servers in one account with one bill.

How the common ways to get a server down alert compare

Most teams already have some form of alerting before they buy one. This is how the usual options behave when the server actually dies at night. Vendor details were checked against each vendor's own pricing page and documentation in September 2026 and change often, so confirm current terms before buying.

Option	Works when the server or its network is down	Phone call alert	How SMS and calls are billed	Repeats while still down
TrackDowntime	Yes, checks from outside	Yes, to every number listed	Included on Professional and Enterprise, not metered	15 rounds over 96 hours
Pingdom	Yes, checks from outside	No, email, SMS and push	SMS credits bundled per plan, 50 a month on the $18 tier	Up to 4 resends
UptimeRobot	Yes, checks from outside	Yes, on paid plans	SMS and voice use credits that do not renew with the plan, packs sold separately	Not stated on the pricing page
Zabbix or Nagios on your own box	Only if hosted on a separate network	Needs a third party gateway	Whatever the gateway charges	Configurable
Cloud provider alarms	Partly, a regional failure can affect both	Needs an extra service	Per message charges from the provider	Configurable
A cron script that sends email	No, it stops with the server	No	Free, and silent when it matters	No

TrackDowntime plans: Starter $29 a month for 5 endpoints at 5 minute checks with email alerts; Professional $99 for 25 endpoints at 60 second checks with SMS and phone call alerts; Enterprise $299 for unlimited endpoints and unlimited history. Annual billing runs at roughly half the monthly price.

Questions people ask before they buy server down alerts

How do I get notified when my server is down?

Add the server's public URL or health check route to an external monitoring service, set a 60 second check interval and put your mobile number on the alert. When the check fails, the service calls and texts you. On TrackDowntime phone and SMS alerts are included from the Professional plan at $99 a month for 25 endpoints.

Can I get a phone call when my server goes down?

Yes. On Professional and Enterprise, TrackDowntime places an automated voice call and sends an SMS to every number on the endpoint as soon as an outage is confirmed. If nobody fixes it, the call repeats at 5, 10, 15, 20, 30, 40, 50 and 60 minutes and then at longer intervals for up to 96 hours.

How do I monitor if a server is down?

Monitor it from outside its own network. A script or agent on the server stops working when the server does, so it cannot report the failure. An external HTTP check against a health endpoint every 60 seconds catches a crashed machine, a failed web process, a broken database connection and a network outage, all from the view a customer has.

Does TrackDowntime monitor ping or open ports?

No. Checks are HTTP and HTTPS requests with an expected status code and a timeout, plus SSL certificate checks. For web and application servers this is usually the stronger signal, since a server can answer ping while every page errors. If you need raw TCP or ICMP checks for non web services, use a tool built for that alongside it.

Will I get an alert when the server comes back up?

Yes. When a check succeeds again the incident is closed and a recovery SMS and email are sent, so whoever was woken up knows it is fixed without logging in. Recovery does not place another phone call. The incident is saved with its start time, end time and measured duration.

Can server down alerts go to more than one phone number?

Yes. Enter several numbers on the endpoint, separated by commas, and every one of them receives the call and the SMS on each alert round. Teams usually list the person on call plus a backup, so a phone on silent does not decide how long the server stays down.

How much does a server down alert service cost?

Expect roughly $10 to $100 a month depending on how many endpoints you watch and whether voice calls are included or sold as credits. TrackDowntime is $29 a month for 5 endpoints with email alerts, and $99 a month for 25 endpoints at 60 second checks with calls and SMS included. Annual billing is about half that.

Will a short network blip trigger a phone call?

Usually not. A timeout is rechecked twice, five seconds apart, and a DNS timeout three times, ten seconds apart, before an incident opens and anyone is called. A clear error code such as 500, 502 or 503 alerts on the first check, because the server has already reported that it is failing.

Let the server call you before a customer does

Add the health endpoint of the server you would least like to lose tonight, list the phone numbers that should ring, and monitoring starts with the next check. Professional covers 25 endpoints at 60 second checks with phone call and SMS alerts for $99 a month, never billed per message.

Compare plans

Keep reading

Downtime alerts by phone call

How the automated call, SMS and email escalate for website outages, and what the call says.

Downtime monitoring

What counts as down, how rechecks filter false alarms, and how APIs are checked with real headers.

Website downtime tracker

Every incident logged with start, end and duration, and how long each plan keeps the history.

Pingdom SMS alerts cost and alternatives

What Pingdom's SMS credit bundles cost per tier and when a plan with included calls works out cheaper.

Uptime monitor pricing

Endpoints, check interval, history retention and alert channels on each plan.

Downtime alerts for small business

Alert services compared on price, voice calls and how quickly an outage reaches a person.

Server Down Alert: Notify When Server Is Down With a Phone Call and SMS