The service never reloaded
A new certificate is written to disk but the web server, proxy, or container is still holding the old one in memory until it restarts.
Days remaining
An SSL expiration monitor for the renewal that quietly did not land
Most expiry incidents are not forgotten renewals. They are renewals that completed somewhere and never reached the socket serving traffic. ExpiryBeacon measures the certificate the server actually presents, so the countdown reflects reality rather than intent.
Where the countdown comes from
Days remaining is derived from the notAfter value on the leaf certificate returned during a live handshake, compared against the time of the check. It is rounded down to whole days, so a certificate with 30 days and 20 hours left reads as 30 days.
Because the figure comes from the served certificate rather than from a renewal system, a monitor and an ACME client can disagree — and when they do, the monitor is describing what your visitors get. That disagreement is the signal worth having.
Both dates are shown in UTC. Certificate validity is defined in UTC, and a local rendering is one of the easier ways to be an hour wrong about a deadline.
Why a renewal can succeed and still fail
These are the ordinary failure modes an expiration monitor is meant to catch. Each one leaves the renewal log looking healthy.
The wrong endpoint got it
One node in a pool, one virtual host, or one load-balancer listener renewed. The others keep serving the previous certificate.
The edge holds its own copy
A CDN, load balancer, or WAF terminates TLS with a certificate uploaded separately from the origin's renewal process.
The chain changed
The leaf renewed but the intermediate shipped alongside it did not, so some clients can no longer build a path to a trusted root.
Setting up an expiration monitor
Check the endpoint first
Run the hostname through the checker and confirm the result describes the endpoint you meant — the resolved address, port, and covered names are all shown.
Save it as a monitor
Signing in with Google stores the monitor against your account, which is what enables the daily scheduled check and the durable history.
Set the warning window
Choose 30, 14, or 7 days per monitor. The window should be longer than your slowest realistic renewal path, not shorter.
Turn on email alerts
Alerts are off until you enable them and set a notification address in the account policy. Until then the monitor still checks and records; it simply does not mail you.
What each state means
| State | How it is decided |
|---|---|
| Healthy | The chain validates and days remaining is above the monitor's threshold. |
| Warning window | Days remaining has fallen to the threshold you chose — 30, 14, or 7 — while the certificate is still trusted and valid. |
| Trust warning | The certificate is still inside its validity window but the chain does not validate against the public root store. The reported reason distinguishes a self-signed certificate, a missing intermediate, and a hostname the certificate does not cover. |
| Expired | The notAfter date has passed. This takes precedence over every other state. |
| Check failed | The endpoint could not be reached or did not present a certificate. Previous evidence is kept and shown with its original timestamp. |
When an email is sent, and when it is not
Email alerts are opt-in per account and go to one address you set. Delivery is driven by a state change, never by a schedule, so a monitor that stays in the same state stays quiet.
- A monitor crosses into its warning window (30, 14, or 7 days, whichever you chose).
- A certificate stops validating against the public root store.
- A certificate passes its expiry date.
- A scheduled check cannot complete — for example the host stops resolving or the handshake times out.
- A monitor returns to healthy after any of the above, which sends a single recovery message.
- Repeats of a state already notified are suppressed, so an expiring certificate does not mail you every morning.
Current limits
- One scheduled check per monitor per day, from a single region.
- Ports 443, 8443, and 9443 only.
- Public hostnames only — no IP literals, private ranges, or internal names.
- Email delivery only; no webhooks, chat integrations, or paging.
- Up to 50 monitors per account, with the 20 most recent checks shown per monitor.
Questions about ssl expiration monitor
How many days before expiry will I be warned?
Whichever window you set on that monitor: 30, 14, or 7 days. The threshold is per monitor, so a hand-renewed certificate and an automated one can have different windows.
What if the certificate is replaced between checks?
The next check reads the new certificate and the days-remaining figure moves with it. The SHA-256 fingerprint and serial number also change, which is the reliable way to confirm a renewal actually reached the endpoint.
Does an expiration monitor tell me the site is down?
No. ExpiryBeacon reports certificate state only. If a check cannot complete you will see that the check failed, but that is not a substitute for uptime monitoring.
Can I monitor a certificate that is already expired?
Yes. An expired certificate is still inspected and recorded — the days-remaining figure simply reads as days since expiry, and the state is reported as expired.