How to Get Notified When Nginx Crashes (systemd + Free Monitoring)

Nginx crashing is rarely dramatic. There's no alarm, no red banner — just a site that quietly stops responding while you're asleep, in a meeting, or three tabs deep in something else. The first sign is usually a customer, not a system.

Why Nginx goes down more often than people expect

Nginx itself is stable, but it's rarely the only thing running. A worker process gets OOM-killed under memory pressure, a bad config gets pushed and reload silently fails, a certificate expires and every HTTPS request starts erroring, or the app behind it (Node, FastAPI, PHP-FPM) crashes and Nginx has nothing to proxy to. From the outside, all of these look identical: the site is down.

The fix that actually matters: auto-restart, not just alerts

Before you even think about notifications, make sure Nginx and whatever it's proxying to can restart themselves. On a systemd-based server, this is one file.

[Unit]
Description=Your App
After=network.target

[Service]
Type=simple
User=youruser
WorkingDirectory=/path/to/app
ExecStart=/path/to/venv/bin/python3 main.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Restart=always with a short RestartSec means a crashed process comes back in seconds instead of staying down until someone notices and SSHes in. This alone eliminates most "it crashed overnight and nobody knew" incidents.

For Nginx specifically, it already ships with a systemd unit, so confirm it's enabled:

sudo systemctl enable nginx
sudo systemctl status nginx

Auto-restart isn't enough on its own

A process can restart and still be broken — stuck in a crash loop, serving 502s, or up but unable to reach its database. Restart policies fix the process; they don't tell you it happened. You still need something checking from the outside, the same way a visitor would hit your site.

A server that silently restarts itself ten times overnight is not a healthy server. It's a server you don't know is sick yet.

What to actually check, and how often

• HTTP status code — a 200 with the process "running" can still be a broken app returning an error page.
• Response time — a site that takes 15 seconds to respond is functionally down for most visitors, even without erroring.
• Check frequency — checking once an hour means up to an hour of silent downtime. Every few minutes closes that gap to something reasonable.

Getting notified the moment it happens

Email alerts get missed — they land in a pile with everything else. Something that pushes a notification straight to your phone the second a check fails is what actually gets you moving before a customer emails you first.

This is exactly the gap we built PingKeeper to close: it checks your site every 60–300 seconds and sends an instant Telegram alert the moment something breaks — free for up to three monitors, no credit card needed. Combined with a proper Restart=always systemd service, you get both halves of the fix: the server heals itself, and you find out it happened.