"Renewal Succeeded" and "Everything's Fine" Are Different Claims
A full certificate update has four stages: request from the CA, complete domain validation, deploy the new certificate to every TLS endpoint, and confirm users actually receive it. ACME tooling handles **the first two**; the third depends on your configuration; and almost nothing does the fourth for you automatically.
That's where the gap opens. A renewal log reading `success` means the certificate was obtained, not that it's being served. Deployment and reload still sit in between, and a failure at either never shows up in the renewal log.
| Approach | Catches | Misses |
|---|---|---|
| Calendar reminders / expiry list | When action is due | Whether renewal succeeded or deployed |
| ACME renewal logs | Whether a certificate was issued | Whether the new certificate is served |
| Local check of the certificate file | What's on that particular machine | CDN nodes, load balancers, other endpoints |
| External connection check | What users actually receive | (the only approach that proves nothing is wrong) |
The table below lays out four common monitoring approaches. The important column is the third — what each one **misses** is exactly where incidents happen.
Three Ways Renewal Succeeds and Things Still Break
All three are real situations where the renewal log said success and users still saw warnings:
- The new certificate didn't reach every endpoint If traffic passes through a CDN, load balancer, or several backends, the certificate has to update everywhere TLS terminates. Updating the origin while CDN nodes still serve the old certificate is the most common version. Because only some nodes are affected, reports come in as "some people say it's broken, others say it's fine" — which makes diagnosis harder.
- Certificate and private key don't match The certificate is replaced but the private key isn't updated in step (or vice versa), and the service refuses to load it. This usually errors on reload — but if nobody is watching logs, the error gets swallowed and the service keeps running on the old certificate held in memory until it expires.
- The file updated but the service never reloaded This is the most insidious one. The certificate file on disk is new, a local check looks fine, but Nginx, Apache, or the application is still using the old certificate loaded into memory at startup. Everything looks correct from the server; connect from outside and you get a certificate about to expire.
What to Monitor, and When to Alert
Those three situations point to one principle: **monitoring has to originate outside your network, against the address users actually reach**. A check from inside the facility or on the same machine cannot prove that every layer on the public path received the new certificate.
What you check shouldn't be limited to the expiry date either. Cover at minimum: expiry time, whether the chain is complete (a missing intermediate fails on some clients), whether the served certificate matches the expected domain, and — if you run multiple nodes — whether every node serves the same certificate.
Also confirm where alerts land. Mail to an unwatched inbox, or a red dot on a dashboard nobody opens, is equivalent to no alerting at all. Route it into a channel the team actually reads, and name someone responsible.
Shorter Lifetimes Move This From Optional to Required
When certificates lasted 398 days, you handled this once a year, and imperfect monitoring carried limited risk. Lifetimes dropped to 200 days in March 2026, fall to 100 days in 2027, and to 47 days in 2029 — roughly eight renewals a year at that point.
Every renewal is another chance to fail. Going from once a year to eight times a year means **the same failure rate produces eight times as many incidents**. That's why monitoring stops being a nice-to-have in the short-lifetime era and becomes automation's necessary counterpart: automation makes the frequency survivable, and monitoring is what confirms those automated updates actually took effect.
Three Layers of Implementation
From the basics up, this can be built in stages:
1. Scheduled external connection checks
The basic version is a scheduled job that opens a TLS connection to each public domain, reads the certificate actually served, and compares the expiry date. On the command line, `openssl s_client -connect
2. Cover every TLS endpoint
List everywhere TLS terminates — origin, each CDN node, load balancers, API domains, mail servers. Checking only the main domain misses the rest. If your CDN has multiple nodes, ideally run checks from several regions, since node certificate updates don't always propagate in step.
3. Fold deployment verification into the automation
The fuller approach makes verification part of the renewal flow itself: after issuing and deploying, automatically confirm from outside that the new certificate is being served, and treat a failed confirmation as a failure of the whole flow. Only then does "renewal succeeded" actually mean "users have the new certificate" rather than "the file downloaded".
Three Things to Establish First
Before configuring anything, take stock of these:
- Enumerate every TLS endpoint Main domain, subdomains, API, mail, and each CDN or load balancer node. Endpoints missing from the list won't be monitored, and they'll show users warnings just the same.
- Confirm checks run from outside The monitoring host must sit outside your network, taking the path users take. Internal checks skip the CDN and external load balancers — precisely the layer most often missed.
- Confirm someone sees the alerts Name the channel and the owner. Once thresholds are set, fire a test alert and confirm delivery — plenty of monitoring setups discover on incident day that the notification path broke long ago.
In Summary
Certificate automation solves "renewing is tedious". Monitoring solves "did the renewal actually take effect". Both need to exist — automation without monitoring hands a high-frequency process entirely to a mechanism nobody checks, and shrinking lifetimes are pushing that frequency toward eight times a year.
There's a single question that tells you whether your monitoring is sufficient: **does it check the certificate file, or what users actually receive?** If it's the former, it catches none of the three situations described above.