Setting up an alert for when your server goes down

Setting up an alert for when your server goes down

You find out before your customers by monitoring from outside your network for the things that prove your service is working. Add HTTP status plus content checks, port checks and heartbeats for background jobs. Pair that with disk and certificate checks on the server, and route alerts to a channel that actually wakes you.

This picks up from a server you can already reach over SSH.

Before you start

• Decide what “up” means for you. A ping is not enough. UptimeRobot’s own FAQ says ping is not a good fit for monitoring websites because a host can reply to ICMP while the site itself is down. Prefer HTTP or HTTPS, Port and Keyword monitors for app-level truth.
• Plan for checks every 5 minutes on the UptimeRobot Free plan. Faster intervals need a paid tier.
• Expect UptimeRobot to confirm problems from multiple regions before alerting. This reduces false positives.
• If you prefer self‑hosting, Uptime Kuma supports HTTP/HTTPS checks with optional body keyword matching and certificate expiry notifications, and can export Prometheus metrics.
• Add heartbeat monitoring for cron and backup jobs. Healthchecks‑style monitors send an HTTP ping when a job completes and alert if a ping is late or missed.
• Route urgent alerts to a waking channel. Pushover can repeat “emergency” priority notifications until you acknowledge, and its iOS app supports Critical Alerts that bypass mute or Do Not Disturb. Relying on email alone can fail, especially without proper SPF, DKIM and DMARC. UptimeRobot integrates with Slack, Teams, Telegram, Pushover and webhooks so you can choose what will wake you.
• Watch disk blocks and inodes. Inode exhaustion breaks writes even when “df -h” looks comfortable.
• Keep certificate renewals in hand. Let’s Encrypt certificates are 90‑day by design. Verify renewals and add an independent expiry check.

Risks to avoid

• Do not hand‑edit or delete files under /etc/letsencrypt/live or /etc/letsencrypt/archive. Use certbot subcommands and hooks. Editing the symlinks can break renewals.
• On Ubuntu 24.04, Certbot via Snap is the recommended install. Remove any old apt/dnf/yum Certbot first to avoid conflicts.
• Treat heartbeat URLs as secrets. If someone else knows the URL, they can spoof “all good” and hide failures.
• Do not clear space by deleting random log files. Deleted‑but‑open files do not free space until the writer restarts. Verify with lsof +L1 and restart writers cleanly.
• Set journald caps with care. Too‑low limits can prune logs needed for incident analysis.

Step 1: Add external checks that prove your service works

Do this first. An independent monitor is what lets you know before a customer calls.

• Create an HTTP or HTTPS check for your public URL. Use status‑code monitoring together with a content/keyword check. Vendor docs recommend pairing status checks with a keyword so you catch the “200 OK but broken page” case.
• Add a Port monitor for any critical TCP service your app depends on, for example your web server’s port.
• Optionally add a Ping monitor for basic reachability. Keep it as a secondary signal, not the only one.
• If you have background jobs, add a Heartbeat/API monitor so a late or missed completion raises an alert.
• On UptimeRobot Free, set your expected 5‑minute interval. Faster intervals require a paid tier.
• Expect multi‑location confirmation before an alert. This reduces one‑off network blips.
• Note for SSL expiry on UptimeRobot: the SSL check toggle for HTTPS monitors is not available on the Free plan.

Tools:

• UptimeRobot: HTTP(s), Ping, Port, Keyword and Heartbeat monitors, multi‑location confirmation, many integrations.
• Uptime Kuma (self‑hosted): HTTP/HTTPS with optional keyword matching, certificate expiry notifications, Prometheus export.

If you are moving production traffic to us, set this up as part of go‑live. If you need help deciding which endpoint to monitor on your Hostworld VPS or cPanel hosting, open a support ticket.

Step 2: Route alerts to something that wakes you

Configure paging before you depend on monitoring.

• Pick a push or paging channel. Pushover “emergency” priority repeats until you acknowledge, and its iOS app can use Critical Alerts that bypass mute and Do Not Disturb.
• Avoid email‑only alerts. Mail can be delayed or filtered. Recent Gmail sender requirements make unauthenticated mail more likely to be rejected.
• Use UptimeRobot’s integrations to send alerts to Slack, Microsoft Teams, Telegram, Pushover or a webhook.
• Test acknowledgement flows so repeated alerts stop when you act.

Step 3: Install Monit and add disk and inode alerts

These commands install Monit, which can alert when a filesystem is close to full. You will add conditions for both disk space and inodes.

AlmaLinux 9

Enable EPEL, then install Monit from packages.

This installs the EPEL repositories that provide Monit:

sudo dnf install -y epel-release epel-next-release

This installs Monit:

sudo dnf install -y monit

This enables Monit at boot and starts it now:

sudo systemctl enable --now monit

Ubuntu 24.04

Update apt metadata, then install Monit.

This refreshes package lists:

sudo apt update

This installs Monit:

sudo apt install -y monit

This enables Monit at boot and starts it now:

sudo systemctl enable --now monit

Add filesystem alerts in Monit

Add rules to your Monit configuration so it sends an alert when space or inodes are tight. Place these in your Monit configuration according to your distro’s layout, then reload or restart Monit.

check filesystem rootfs with path /
  if space usage > 85% then alert
  if inode usage > 90% then alert

This restarts Monit to pick up the changes:

sudo systemctl restart monit

Start with alert‑only. Automatic restarts or cleanups on databases or queues can cause data loss. If you later add automatic actions, stage them carefully.

Step 4: Check disk and inodes now, and fix the common gotcha

Do a one‑off health check so you know your baseline.

AlmaLinux 9

This shows block usage in human‑readable units:

df -h

This shows inode usage. Inode exhaustion can stop writes even when blocks look fine:

df -i

If deleting files did not free space, this finds deleted‑but‑open files that still consume disk until the writer restarts:

sudo lsof +L1

Ubuntu 24.04

This shows block usage in human‑readable units:

df -h

This shows inode usage. Inode exhaustion can stop writes even when blocks look fine:

df -i

If deleting files did not free space, this finds deleted‑but‑open files that still consume disk until the writer restarts:

sudo lsof +L1

When you find a large deleted‑but‑open file, restart the owning service cleanly so it releases the handle. Verify space returns after the restart.

Step 5: Cap journald’s log size so logs do not eat the disk

Systemd’s journal can grow quickly. Set limits now rather than in an incident.

Add or adjust these options in your journald configuration. Choose values that fit your disk size and retention needs.

[Journal]
SystemMaxUse=1G
SystemKeepFree=15%
RuntimeMaxUse=200M
RuntimeKeepFree=15%

This restarts journald to apply the new limits:

sudo systemctl restart systemd-journald

Do not set the caps so low that you lose logs you need for incident analysis. Journald will not retroactively shrink if another process fills the filesystem, so set these limits proactively.

Step 6: Stay ahead of SSL certificate expiry

Use two layers. First, external expiry alerts so you hear about problems even if renewals fail. Second, verify local renewals.

External alerts

• Uptime Kuma can send certificate expiry notifications for your HTTPS monitors.
• UptimeRobot offers SSL certificate monitoring with advance warnings on paid plans. On Free, the SSL check toggle is not available.

Verify Certbot auto‑renew on Ubuntu 24.04

On Ubuntu 24.04, Certbot via Snap sets up a systemd timer that handles renewals. Remove any old apt/dnf/yum Certbot before installing the Snap build to avoid command conflicts.

This shows the timer’s status:

systemctl status snap.certbot.renew.timer

This lists the next scheduled runs for the Certbot timer:

systemctl list-timers 'snap.certbot*'

This confirms the Snap is installed:

snap list certbot

Do not hand‑edit or delete files under /etc/letsencrypt/live or /etc/letsencrypt/archive. Use certbot subcommands and renewal hooks for management. Let’s Encrypt certificates last 90 days by design, so check that renewals keep happening long before expiry.

Scripted expiry checks with OpenSSL (either OS)

If you have a local certificate file to hand, use OpenSSL to report the expiry date or exit non‑zero when it is too close.

This prints the certificate’s expiry date:

openssl x509 -in /path/to/cert.pem -noout -enddate

This exits with status 0 if the certificate is valid for at least 30 more days, or 1 if it expires sooner:

openssl x509 -in /path/to/cert.pem -noout -checkend 2592000

Use that exit code in a cron job to alert early. Keep the alert path independent from the server where possible so you still hear about issues if the host is unavailable.

Step 7: Monitor cron and backup jobs with heartbeats

Background tasks fail quietly. Heartbeat monitoring alerts you when a job does not complete on schedule.

• Create a new heartbeat check. Healthchecks‑style services let you define schedules by interval, crontab expression or systemd OnCalendar.
• Add an HTTP “ping” to the end of each job. The service notifies you if a ping is late or missing.
• Treat the heartbeat URL as a secret. If it leaks, a third party can spoof a success and hide a failure.
• If you use UptimeRobot, Heartbeat/API monitors are available there as well.

Step 8: Test and rehearse your alerts

• Trigger an HTTP content failure by changing the expected keyword on one monitor to a value that is not on the page. Confirm you receive an alert, then restore the keyword.
• Lower a Monit threshold to trigger a space or inode alert, then return it to normal. Confirm the alert path behaves as expected.
• If you use Pushover emergency priority, confirm repeated notifications stop when you acknowledge.

We can sanity‑check your setup on a Hostworld VPS or cPanel hosting plan. If you want an engineer to review your monitors, open a support ticket.

What next

• Keep building your runbook with the rest of our VPS guides.
• If you are planning new capacity or want a second site in the UK or US, see our Linux VPS.