An SSL/TLS certificate rarely fails out of nowhere. Before the browser shows a warning page and users bounce, there is a deadline quietly counting down. The expiry date is fixed — it is written into the certificate itself — and it does not degrade over time. The certificate works perfectly until the second before expiry and stops being accepted the second after. There is no middle ground, no partial validity, and no built-in notification that the server sends to itself.
That sharp transition between valid and invalid is what makes certificate expiry a predictable operational problem and, at the same time, one of the most common causes of avoidable downtime in production.
What expiry actually means
An X.509 certificate contains, among other fields, two timestamps: notBefore and notAfter. The notAfter field is what we call the expiry date. When a TLS client — a browser, curl, another service calling your API — receives the certificate during the handshake, it compares the current clock against that window. If the clock is past notAfter, the connection is terminated before any application byte travels.
Certificates issued by public CAs today have a maximum validity of 395 days. That means every public hostname must go through a renewal at least once a year. Environments using Let's Encrypt renew every 60–90 days, automatically in most cases — but "most" is not "always". Hooks fail, DNS does not propagate, tokens expire, and the cron job that was supposed to renew silently stops running.
What to check before expiry
Days remaining is the obvious metric, but it is not the only one. A useful review of a public certificate considers at least four signals:
- Days until
notAfter. Under 30 days is a signal to schedule renewal; under 7 days, an emergency. - Issuer (CN/O of the issuer). Knowing who issued the certificate tells you which renewal flow to use — ACME, the issuer's dashboard, a file sent by email.
- Covered hostname (CN and Subject Alternative Names). A certificate may cover
example.comand notwww.example.com. Renewing the wrong one is a common mistake. - Trust chain. The leaf certificate must reach the client together with the correct intermediates. A server can deliver a valid certificate and still cause a browser error if the chain is incomplete.
That last point deserves attention. An incomplete chain is not an expiry problem, but it often shows up alongside one in diagnostics because the symptom looks similar: the browser complains, curl complains, and the root cause is different. Command-line tools like openssl s_client -showcerts and curl -vvI show the full chain the server delivers.
Why monitor from outside
A common trap is relying only on internal monitoring. An agent running inside the server knows the certificate file exists, but it does not necessarily see what the server delivers on port 443. A misconfigured reverse proxy may keep serving an old certificate even after ACME renewed. A load balancer may terminate TLS with a different certificate than the application expects.
An external check — coming from outside the network, the way a real client would — catches that kind of mismatch. It answers the question "what is a visitor actually receiving right now?", which is the only one that matters from the perspective of someone accessing the service.
Turning alerts into work items
An alert without an owner becomes noise. The difference between useful monitoring and an ignored dashboard is turning each signal into an action with a responsible person and a deadline.
In practice:
- Define clear thresholds: 30 days to start working on it, 14 days to escalate, 7 days to treat as an incident.
- Assign each hostname to an owner — a person, a team, or a runbook.
- When the alert fires, the action should already be described: "renew via ACME", "update certificate on the load balancer", "review the chain with the issuer".
- Record what happened. Renewal history serves both audit purposes and pattern detection — a certificate that needs manual renewal every time is a candidate for automation.
The goal is not to accumulate metrics. It is to know, at any moment, how many days of validity remain on critical certificates and what the concrete next step is for each one.
Next step
If you do not know today how many days remain on your public hostnames' certificates, that is the starting point. An external scan, even a manual one with openssl s_client, gives you the answer in seconds. From there, the work is building the loop: measure, compare against the threshold, act, record.
Tools like cymesh automate that cycle — they run continuous external checks, compare against configurable thresholds, and keep history — but the principle is the same regardless of the tool: the certificate expires on a fixed date, and the only way to avoid being caught off guard is to look before it happens.