← Blog  ·  October 2026

Nginx SSL Certificate Monitoring: Automated Expiry Alerts for Your Web Server

Your Nginx cert is valid today. In 27 days it won't be. Here's how to know before that happens.

SSL certificate expiry is one of the most preventable outages in web infrastructure — yet it catches DevOps teams off-guard constantly. An expired cert on your Nginx server doesn't just degrade the experience: modern browsers block the request entirely, returning a full-page warning before users can even see your site. If the cert serves an API endpoint, every downstream client starts failing at the same moment.

The reason it still happens: the default workflow is manual. Someone checks the cert when they remember, adds it to a calendar, hopes the reminder fires on time, and eventually gets burned anyway. This article covers how Nginx SSL certificate monitoring should work and how to set it up properly.

The manual approach: openssl s_client

The standard command-line check for any SSL cert is:

echo | openssl s_client -servername yourdomain.com \
  -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -dates

This outputs the notAfter field — the expiry date. You can turn it into a cron-based alert with a few more lines:

#!/bin/bash
DOMAIN="yourdomain.com"
EXPIRY=$(echo | openssl s_client -servername "$DOMAIN" \
  -connect "$DOMAIN:443" 2>/dev/null \
  | openssl x509 -noout -enddate \
  | cut -d= -f2)

EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s 2>/dev/null \
  || date -j -f "%b %d %T %Y %Z" "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt 30 ]; then
  echo "WARNING: $DOMAIN SSL cert expires in $DAYS_LEFT days" \
    | mail -s "SSL Expiry Alert" ops@yourcompany.com
fi

Add it to crontab to run daily:

0 8 * * * /opt/scripts/ssl-check.sh >> /var/log/ssl-check.log 2>&1

This works for a single domain. It's what most teams start with.

Why the manual approach breaks down

The openssl + cron approach has hard limits that matter once your infrastructure grows:

• One domain at a time. If you're running 5 Nginx vhosts, 3 subdomains, and 2 staging environments, you're maintaining separate scripts or comma-separated loops — fragile and easy to miss when a new domain is added.
• No alerting by default. The script only alerts if mail is configured and the local MTA is working. On a fresh server or a container, that's usually not the case. The check runs silently and produces no output.
• Container and ephemeral environments. A cron job in a container doesn't survive restarts. A job on an autoscaled instance runs multiple times. A job on a deprovisioned instance doesn't run at all. None of these are visible failures — they look like the check ran normally.
• No escalation tiers. Getting one alert at 30 days is less useful than getting alerts at 30, 14, 7, and 1 day before expiry. An alert at 30 days is easy to defer. An alert at 1 day is not — but if your monitoring only fires once, and you deferred it, you won't get reminded.
• No certificate chain validation. A cert can be technically valid but have an intermediate chain problem that causes browser errors on specific clients. openssl s_client doesn't reliably surface this.

How Nginx SSL monitoring should work

Proper Nginx SSL certificate monitoring has four properties:

1. Domain-agnostic. Add a domain once; the monitoring service checks it on a schedule without requiring changes to your Nginx config, crontab, or scripts.
2. Multi-tier alert schedule. Alerts at 30, 14, 7, and 1 day before expiry — not a single one-time notice that's easy to dismiss.
3. Delivery to where you actually read alerts. Email to your ops address, not local mail spool. Ideally with a link that shows current status without requiring a login or terminal access.
4. Infrastructure-independent. The check happens outside your server — monitoring a Nginx cert from the same host it's served on means a server outage can also kill the monitoring. An external check catches problems your internal tooling can't.

Using SSLWatch for Nginx SSL expiry alerts

SSLWatch is designed for exactly this use case: you enter a domain, and SSLWatch monitors the SSL certificate externally and emails you before it expires. It works for any Nginx-served domain — single server, reverse proxy, wildcard cert, or Let's Encrypt — without touching your Nginx config or server.

The alert schedule follows the tiers that matter in practice:

• 30 days: advance notice with plenty of time to act
• 14 days: reminder if the first alert got buried
• 7 days: urgent — schedule renewal this week
• 1 day: emergency — renew immediately

This is structurally different from a one-off script: the alerts repeat on a schedule you don't have to maintain. When you renew the cert, SSLWatch detects the new expiry and resets the alert window automatically.

Check your Nginx SSL certificate right now

Before setting up monitoring, check the current status of your cert. Enter your Nginx domain into the free SSL checker:

The checker shows you exactly what an external client sees when it connects to your domain — the same view a browser uses to validate the cert. If there's a mismatch between what Nginx serves and what you expect, it surfaces here.

Turn manual checks into automated peace of mind

The openssl command is useful for a one-time inspection. It's not a monitoring strategy. A monitoring strategy means:

• every domain you serve is covered
• you get alerted with enough time to act
• the alert fires even when your server is down
• you don't have to remember to check

Nginx SSL certificate expiry is a solved problem — the only reason it catches teams off-guard is because the default tooling requires you to set up something manually, and manual setups drift. External monitoring that sends alerts at 30, 14, 7, and 1 days is the durable answer.

← All articles  ·  SSLWatch  ·  Free SSL checker