Domain Monitoring with SSL Alerts: The Complete 2026 Setup Guide

Last week a Fortune 500 company lost an estimated $14 million in roughly six hours because a single SSL certificate quietly expired and nobody noticed until customers started complaining on Twitter. The renewal email had been sent. It went to a shared inbox that the previous DevOps lead used to own. He left in March. The certificate expired on a Saturday at 02:14 UTC. The on-call engineer for the platform team didn't get paged because nothing was technically "down" — the site was serving traffic, just with a giant red browser warning that scared every paying customer away.

This is not an unusual story. It's the most common preventable outage we see, and it has nothing to do with cloud architecture or container orchestration. It happens because most teams treat domain monitoring, SSL monitoring, and uptime monitoring as three separate problems handled by three separate tools — or, more often, by nobody at all. This guide walks through the full 3-layer stack, what to monitor at each layer, and how to wire it up so you never get blindsided again.

The 3-Layer Monitoring Stack#

Every public-facing web property has three independent failure modes that each cause "the site is down" symptoms but require completely different remediation:

1. Domain expiry — your registration lapses, the registrar takes the domain back, and your DNS stops resolving. Recovery time: hours to days. Cost: catastrophic.
2. SSL certificate expiry — DNS still resolves, the server is still up, but the certificate is past its notAfter date. Browsers block the connection. Recovery time: minutes if automated, hours if manual.
3. Uptime / HTTP failure — DNS resolves, the cert is valid, but the server returns a 5xx, times out, or has been redirected to a parking page by your hosting provider. Recovery time: depends entirely on root cause.

The reason all three layers are needed is that each catches a failure that the others miss. Uptime monitoring will tell you the site is broken — but only after the SSL cert has already expired and customers have already churned. Domain monitoring catches the registration lapse weeks before the domain actually drops. SSL monitoring catches the cert problem 30 days before the browser warning appears. Stack all three and you get layered defence; skip any one and you have a hole big enough to drive a truck through.

Layer 1: Domain Expiry Monitoring#

Domain expiry is the most preventable outage on the internet, and also the most embarrassing. Microsoft has done it. Google has done it (twice). Foursquare did it. Sorenson Media did it. Every one of these was a multi-hour outage caused by a credit card on file expiring or a renewal email going to the wrong inbox.

Why Registrar Emails Are Not Enough#

Registrars send renewal reminders. They go to whatever email address was on file when the domain was first registered, which is frequently the personal Gmail of a contractor who left three years ago. Even when the address is correct, registrar emails routinely land in spam, and even when they don't, they look exactly like the phishing emails that pretend to be renewal notices, so people delete them.

Auto-renewal is supposed to fix this, but auto-renewal fails silently in three common ways:

• The credit card on file expires.
• The card is declined for fraud (annual renewals look unusual to issuing banks).
• The registrar's auto-renewal toggle gets flipped during an account migration or a control panel redesign.

External monitoring is the only reliable backstop.

How to Monitor Domain Expiry#

The protocol is RDAP (the modern replacement for WHOIS) with a WHOIS fallback for TLDs that don't yet support RDAP. A daily check is sufficient — domain expiry dates don't move minute-to-minute, and registrars apply their own grace periods on top of whatever you publish.

# Quick manual check via command line
curl -s "https://rdap.org/domain/example.com" | jq '.events[] | select(.eventAction=="expiration")'

Pipe that into a cron job and you have a basic monitor. But you also need alert thresholds, retry logic for transient WHOIS failures, and a way to detect the difference between "expired" and "renewed but the date hasn't propagated yet." That's why a hosted tool is usually faster than building it.

The 30/14/7/2-Day Alert Cadence#

Send alerts at four points: 30 days out (planning), 14 days out (action), 7 days out (escalation), and 2 days out (panic). Anything more frequent creates fatigue. Anything less frequent leaves no buffer if the first alert is missed.

What "Expired" Actually Means#

Domains don't drop the second they expire. Most TLDs have a multi-stage timeline:

• Day 0–30 after expiry: grace period. The domain is suspended (no DNS) but the registrant can renew at the normal price.
• Day 30–60: redemption period. Renewal still possible but with a $80–$200 redemption fee.
• Day 60–90: pending delete. The domain is locked and cannot be renewed.
• Day 90+: dropped. Anyone can register it.

If a domain you own enters redemption, you're probably going to pay for it but you can still recover. Once it's pending delete you're racing professional drop-catchers. Don't let it get there.

Nova Uptime has a free domain expiry checker for one-off lookups, and the dashboard runs RDAP daily on every monitored domain with the 30/14/7/2-day alert cadence built in.

Layer 2: SSL Certificate Monitoring#

SSL certificate expiry is, by a wide margin, the single most common cause of "the site is down" outages. Microsoft Teams went dark in February 2020 because of an expired auth certificate. Microsoft Azure had a multi-hour outage in 2021 from the same cause. Spotify has done it. LinkedIn has done it. Google Voice has done it. The common thread: Let's Encrypt's 90-day rotation cadence has trained the entire industry to expect automation, and when the automation breaks it breaks silently.

What to Actually Monitor on a Certificate#

A certificate has more failure modes than just notAfter. A complete monitor checks:

• notBefore and notAfter — the validity window. Alert at 30, 14, 7, and 2 days before notAfter.
• Issuer chain completeness — your server must serve the full intermediate chain. A common deployment bug is to send only the leaf certificate; this works in Chrome (which caches intermediates) but breaks in Firefox, mobile browsers, and most API clients.
• Subject and SAN match — the certificate's Subject Alternative Names must include the hostname being requested. Wildcard certs are fine but make sure the wildcard actually covers the subdomain you're hitting.
• Cipher suite and TLS version — TLS 1.0 and 1.1 are deprecated. TLS 1.2 is the floor; TLS 1.3 is preferred. Weak ciphers (RC4, 3DES) should fail your check.
• OCSP staple presence — if you've configured OCSP stapling and it stops working, you'll see browser warnings even with a valid cert.

Common SSL Failure Modes#

In rough order of frequency, the failures we see in production:

1. Certificate expired. Auto-renewal hook didn't fire. Cron job died. Renewal succeeded but the new cert wasn't reloaded by the web server.
2. Intermediate certificate missing or wrong. Certbot generates the chain but a deploy script overwrites it, or a reverse proxy is configured with ssl_certificate instead of ssl_certificate fullchain.pem.
3. Hostname mismatch. Cert was issued for example.com but the user is hitting www.example.com and the SAN doesn't include www.
4. Wrong cert served (SNI bug). Server is hosting multiple sites and the default vhost cert is being served instead of the per-site cert.
5. Clock drift. Server clock is more than a few minutes off, making valid certs appear expired or not-yet-valid.

Recommended Check Frequency#

Daily is the minimum. For revenue-critical endpoints — payment APIs, login flows, embedded widgets — hourly is reasonable. The check is cheap (a single TLS handshake per endpoint) so frequency is rarely the bottleneck.

Real-World Cert Disasters#

The pattern repeats every year:

• Microsoft Teams, Feb 2020 — expired internal certificate took down Teams for hours during peak workday.
• Microsoft Azure, March 2021 — TLS cert expiry caused a 14-hour outage affecting authentication across multiple Microsoft properties.
• Spotify, multiple years — expired certificates have caused at least three publicly visible outages.
• GitHub status page — at one point the status page itself served an expired cert, which is the kind of irony that makes engineers nervously laugh.

None of these companies lacked the engineering talent to prevent expiry. They lacked the layered monitoring that would have caught it. Nova Uptime's free SSL expiry checker does a single-shot check; the dashboard runs the same check on a schedule and alerts at 30/14/7/2 days.

Layer 3: Uptime / HTTP Monitoring#

Uptime monitoring is the layer that catches everything the first two layers can't anticipate: server crashes, deploys gone wrong, runaway memory, database connection pool exhaustion, DDoS, hosting provider issues, DNS misconfiguration, CDN cache poisoning, and the fifty other failure modes that don't show up in a cert or a registrar record.

What to Check#

A useful HTTP monitor checks more than just "did the request return 200?" Specifically:

• Status code — anything in the 2xx range is healthy, 3xx might be a redirect to a parking page (suspicious), 4xx and 5xx are failures.
• Response time — p95 latency creeping up is the leading indicator of a database or CPU issue.
• Response body content — ideally check for a known-good string (a heartbeat endpoint that returns {"status":"ok"}) so you catch the case where the server returns 200 but the application is crashed and serving an error page.
• TLS handshake success — folds part of layer 2 into the same check.
• DNS resolution time — a slow DNS lookup is often the first sign of a CDN or upstream issue.

Why Multi-Region Matters#

A single-region monitor is a false-confidence machine. Your monitor lives in us-east-1. So does your application. AWS has a regional issue. Both go down. Your monitor reports "site up" because the monitor is dead. Multi-region monitoring (or, at minimum, cross-region monitoring — monitor in us-west if your app is in us-east) eliminates this class of false negative.

Capture Failure Screenshots#

When a check fails, take a screenshot of the rendered page. This is worth its weight in gold during postmortems because it captures exactly what the user saw at the moment of failure — not what the logs say happened, not what the synthetic monitor thinks happened, but what was on the screen. Was it a 502? A maintenance page? A blank white screen? A Cloudflare challenge? You'll know in two seconds instead of two hours.

Multi-Channel Alerts#

Email is necessary but not sufficient. Email gets buffered, batched, and ignored. Critical alerts need to bypass email and reach a human directly. Nova Uptime supports email, WhatsApp (Baileys, no per-message charges), and outgoing webhooks (HMAC-signed) to integrate with PagerDuty, Opsgenie, Slack, or whatever your incident tooling is.

Setting Up the Full Stack with Nova Uptime#

Here is the practical setup, end to end, in roughly the order you'd do it.

1. Add the domain#

Paste the URL into the dashboard. Nova Uptime runs an immediate HTTP check, an SSL handshake, an RDAP/WHOIS lookup for domain expiry, and a favicon fetch. You see all four results within 60 seconds.

2. Configure the check interval#

Free plan: 15-minute interval. Pro plan: down to 59 seconds. Agency plan: same 59-second floor with higher domain limits. For most marketing sites, 5-minute checks are fine. For payment APIs, 59-second checks are correct.

3. Connect WhatsApp#

In Settings → WhatsApp, scan the QR code once. From then on, every alert can be sent to your WhatsApp number with no per-message cost (Free plan = 1 number, Pro = 3, Agency = 5). WhatsApp delivery is faster and harder to ignore than email.

4. Add CC emails for the team#

On each domain's settings page, add up to 5 CC emails. This is the team distribution list for that specific domain — the homepage might alert the marketing lead, the API might alert the on-call engineer.

5. Test alerts with a deliberate failure#

The single best thing you can do after wiring up monitoring is to deliberately break it once. Point a monitored URL at a hostname that doesn't exist, or temporarily revoke the cert, and watch the alert fire. If it doesn't fire, you've just discovered a config bug at the cheapest possible time.

6. Know when to upgrade#

Free tier covers 5 domains and is enough for personal projects and small teams. The two reasons to upgrade are: (a) you've outgrown 5 domains, or (b) you need check intervals below 15 minutes. Pricing details on the pricing page.

Alert Strategy: Avoiding Fatigue#

The fastest way to ruin a monitoring stack is to over-alert. After three false positives in a week, every engineer on the team starts ignoring the channel, and now you have monitoring with negative value.

Three rules of thumb:

Tier severity. Domain expiry warnings 30 days out are informational — they go to email only. SSL warnings 7 days out are warnings — email plus a Slack channel. Site down for 2+ minutes is critical — WhatsApp, phone-buzzing, paging the on-call. Don't send everything to every channel.

Pause during planned maintenance. If you're deploying, pushing a database migration, or rotating a cert, pause the relevant monitor for the maintenance window. Nova Uptime has per-domain pause and a global "pause all notifications" toggle in Settings. (Monitoring continues — only notifications are paused, so you can review the logs after.)

Rate-limit ongoing-down alerts. Once a domain has been reported down, you don't need a notification every minute. Nova Uptime sends the initial alert, then once-per-hour ongoing reminders (across email and WhatsApp) until the domain recovers. The recovery alert always fires immediately.

Route by channel. Email is good for digests, weekly reports, and informational alerts. WhatsApp is good for critical alerts that need a human in the next 5 minutes. Webhooks are good for automation (auto-creating PagerDuty incidents, posting to Slack, triggering runbooks).

Real-World Disaster Sidebar#

A few notable cases worth knowing:

• LinkedIn, October 2022 — multi-hour SSL expiry on a subdomain that affected message delivery. The main site stayed up; the issue was masked until customers reported it.
• Cloudflare, 2021 — an intermediate certificate chain misconfiguration caused widespread issues for sites using Cloudflare's edge cert service. The leaf cert was valid; the chain was incomplete.
• GitHub Status, multiple incidents — the status page itself has, at various points, served expired certs or had domain registration issues. The lesson is that the meta-monitoring (the thing that tells you when monitoring is broken) is itself something that needs monitoring.

Setup Checklist#

Run through this list and you have layered defence:

• Domain registered with auto-renewal enabled and a working credit card on file
• External domain expiry monitoring with 30/14/7/2-day alerts (not just registrar emails)
• SSL cert monitoring on every public hostname including subdomains and wildcards
• HTTP/uptime monitoring with 5-minute or faster cadence, multi-region if possible
• Failure screenshot capture enabled for visual postmortem evidence
• Alerts routed to at least two channels (email + WhatsApp or webhook)
• Tiered severity (info / warning / critical) so the team doesn't tune out
• Maintenance pause documented in the runbook
• Quarterly fire-drill: deliberately break a check and confirm the alert fires
• Email health check on the alerting domain itself (so the alert email actually delivers — see email health checker)

Conclusion#

Domain monitoring, SSL alerts, and uptime monitoring are not three tools you bolt together. They're three layers of one defence-in-depth strategy, and any monitoring stack that handles only one or two of them will eventually let you down at the worst possible moment. Nova Uptime gives you all three in one dashboard with email and WhatsApp alerts on the free plan. Sign up free and monitor up to five domains in under five minutes.

Related Reading#

• Uptime Monitoring for SaaS Applications — multi-tenant monitoring playbook for SaaS teams
• DMARC Policy Setup Guide — the email-side companion to domain monitoring
• Free SSL Expiry Checker — single-shot certificate analysis
• Free Domain Expiry Checker — RDAP/WHOIS lookup with grace-period status
• Free Email Health Checker — make sure your alert emails actually deliver