Monitoring Nginx Server Uptime: Checks for Your Web Server

Nginx is one of the most widely deployed web servers in the world — serving as a reverse proxy, load balancer, and HTTP server for millions of production applications. While Nginx is known for its reliability and performance, it can still fail: processes crash, configuration changes break routing, upstream servers become unavailable.

Effective Nginx server monitoring combines external HTTP checks with process-level monitoring to give you complete visibility.

What Can Go Wrong with Nginx?

Understanding potential failure points helps you set up the right monitoring:

• Nginx process crash — the nginx process exits unexpectedly
• Configuration error after reload — a nginx -s reload with a bad config causes nginx to fail to start
• Upstream connection failure — nginx is running but the upstream application (gunicorn, node, php-fpm) is down
• Certificate misconfiguration — SSL termination at nginx fails due to certificate issues
• Worker process exhaustion — nginx runs out of worker processes under high load
• Disk full — nginx can't write logs or temp files
• Port binding failure — port 80 or 443 already in use, nginx can't start

External HTTP monitoring catches most of these. If nginx is down for any reason, HTTP checks fail.

Step 1: External HTTP Uptime Monitoring

The most important check is an external HTTP uptime monitor pointing at your server's domain or IP:

Monitor: https://yourdomain.com
Method: GET
Expected status: 200
Interval: 1 minute
Content check: verify page title or unique content

This confirms nginx is running and serving your application correctly. If nginx crashes, this check fails and you receive an alert.

Configure multi-location monitoring to check from multiple geographic regions — a network issue or CDN problem might make your server unreachable from some locations while appearing fine from others.

Step 2: Add an Nginx Status Endpoint

Nginx includes a built-in status module (ngx_http_stub_status_module) that exposes connection statistics:

# In your nginx config
server {
    listen 127.0.0.1:80;
    location /nginx-status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

This gives you active connections, accepted requests, and handled connections — useful for spotting connection exhaustion.

For external monitoring, add a dedicated health location that your monitoring tool can reach:

location /health {
    access_log off;
    return 200 "healthy\n";
    add_header Content-Type text/plain;
}

Monitor https://yourdomain.com/health for a fast, lightweight availability check.

Step 3: Monitor Upstream Services

Nginx in reverse proxy mode forwards requests to an upstream application (Node.js, Python, PHP, etc.). Even if Nginx is running perfectly, a down upstream server causes 502 Bad Gateway errors.

Set up separate monitoring for your upstream application's health endpoint. For example:

• If Nginx proxies to localhost:3000, add a monitor for https://yourdomain.com/api/health (which routes through Nginx to your Node.js app)
• This confirms both Nginx AND the upstream application are working

Also monitor the upstream application's heartbeat if it's a long-running process.

Step 4: Process Monitoring

External HTTP checks confirm your service is accessible from the outside. For server-level process monitoring, use your operating system's process management tools.

Systemd

Configure Nginx as a systemd service with automatic restart:

# /etc/systemd/system/nginx.service
[Service]
Restart=always
RestartSec=5

This restarts Nginx automatically if it crashes. External monitoring detects if the restart loop is failing (Nginx keeps crashing) or if the recovery takes longer than expected.

Nginx Reload vs. Restart

Note the difference:

• nginx -s reload — gracefully reload configuration; workers finish existing requests before reloading
• systemctl restart nginx — full stop and restart; brief unavailability

After any configuration change, test with nginx -t before reloading to catch syntax errors that would prevent nginx from starting.

Step 5: SSL Certificate Monitoring

If Nginx handles SSL termination, monitor your certificate:

server {
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
}

An expired or missing certificate causes nginx to fail to start (or serve SSL errors to users). SSL certificate monitoring with 30-day advance alerts ensures you're never caught with an expired certificate.

Step 6: Log Monitoring

Nginx access and error logs contain valuable information for diagnosing issues:

• /var/log/nginx/error.log — captures nginx errors, upstream connection failures, permission issues
• /var/log/nginx/access.log — all requests with status codes

While log monitoring is separate from uptime monitoring, setting up log aggregation (ELK stack, Loki, Papertrail) means you have detailed context available when your uptime alerts fire.

Common Nginx Failure Patterns and What to Monitor

Domain Monitor provides external HTTP monitoring that catches all of these failure modes from outside your infrastructure.

Alert Configuration for Nginx

For a production Nginx server, configure:

• Immediate SMS + Slack for downtime (check fails)
• Email for SSL expiry warnings (30-day advance)
• Email for domain expiry warnings

Use a 2-failure confirmation count to avoid false alarms from brief network blips between the monitoring server and yours.

Monitor your Nginx server uptime at Domain Monitor.

Related Articles

• "Monitoring CI/CD Pipelines and Deployment Health"
• "Monitoring Docker Container Uptime and Health"
• "Monitoring Redis Cache Availability"