30 days
The default. Right for certificates renewed by hand, by a ticket, or by a supplier who needs notice.
Scheduled checks
SSL certificate monitoring that shows its evidence
A monitor is only useful if you can see what it measured and when. ExpiryBeacon runs one real TLS handshake per saved endpoint per day, stores what the server presented, and emails you only when that state changes.
What one check actually does
Every result on this site comes from a live connection made at the moment you ask for it. Nothing is read from a cache or a third-party database.
Resolve the hostname
DNS is resolved server-side. A pasted URL, a literal IP address, or a name that does not resolve is rejected with a plain-language message.
Check where it points
Every resolved address is tested against loopback, private, link-local, carrier-grade NAT, documentation, and multicast ranges. If any answer is non-public the request stops before a socket opens.
Complete a TLS handshake
ExpiryBeacon connects to the resolved public address while sending the original hostname as SNI, so the server presents the certificate a real visitor would receive. The socket times out after five seconds.
Record the evidence
Validity window, days remaining, trust result, issuer, subject, subject alternative names, SHA-256 fingerprint, serial, negotiated protocol, cipher, and chain depth are returned together.
Every field a check returns
The same fields appear in the signed-out checker and on a saved monitor, so a search visitor sees exactly what an account holder sees.
| Field | What it tells you |
|---|---|
| Valid from / valid until | The certificate's own notBefore and notAfter values, shown in UTC. |
| Days remaining | Whole days between now and notAfter, rounded down. A negative value means the certificate has already expired. |
| Trust result | Whether the chain the server sent validates against the public root store, plus a readable reason when it does not. |
| Issuer | The certificate authority that signed the leaf, taken from the issuer field rather than guessed from the hostname. |
| Subject | The common name and organisation on the leaf certificate. |
| Subject alternative names | The hostnames this certificate actually covers, including wildcard entries. |
| Chain depth | How many certificates the server presented, counting the leaf. A depth of one usually means a missing intermediate. |
| Protocol and cipher | The TLS version and cipher suite negotiated for this connection. |
| SHA-256 fingerprint and serial | Two stable identifiers you can compare against a renewal to confirm the new certificate is actually being served. |
| Resolved address | The public IP the handshake was made against, so a multi-origin hostname is not ambiguous. |
Choosing a warning threshold
Each monitor carries its own threshold. Pick the one that matches how long your renewal path actually takes.
14 days
Suits automated renewal that you still want to verify. Most ACME clients attempt renewal around 30 days out, so 14 days flags an automation that has already missed once.
7 days
A last-resort signal for endpoints where renewal is reliable and you only want to hear about a genuine failure.
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.
What happens when a check fails
A failed check is treated as evidence in its own right, not as a certificate result. Transient network errors — a timeout, a reset connection, a temporary resolver failure — are retried once immediately before the attempt is recorded as a failure.
When an attempt does fail, the monitor keeps the last certificate it genuinely observed. The days-remaining figure, issuer, and fingerprint on screen are still the ones from the last successful handshake, and the failure is shown separately with its own timestamp. A monitoring tool that overwrites verified evidence with an error is worse than one that admits it could not connect.
The check history records the failure alongside successful checks, so a flapping endpoint is visible as a pattern rather than as a single bad morning.
What this page does not claim
Certificate monitoring is a narrow job. These are deliberately outside the current product.
- Uptime, response time, status codes, and application health are not monitored. A certificate can be perfectly valid on a server that is returning 500s.
- Checks run from one region on one schedule. There is no multi-region comparison and no sub-daily interval.
- Delivery is email only. Webhooks, Slack, SMS, escalation policies, and acknowledgement are not implemented.
- Internal and private-network endpoints cannot be reached; there is no agent to install.
- Accounts hold up to 50 monitors, and the check history surfaces the 20 most recent entries per monitor.
Questions about ssl certificate monitoring
How often are certificates checked?
Saved monitors are checked once a day at 08:00 UTC. You can also run an on-demand check on any monitor at any time, and the result is written to the same history.
Do I need an account to monitor a certificate?
The checker works signed out, but scheduled daily checks, durable history, and email alerts require signing in with Google. Signed out, a saved endpoint lives only in your own browser.
Will I get an email every day while a certificate is expiring?
No. Alerts fire on a change of state and the last notified state is remembered, so a monitor sitting inside its warning window stays quiet until something else changes or it recovers.
Can it monitor a certificate on an internal server?
No. Every resolved address is validated as public before a connection is attempted, and requests to private or reserved ranges are refused. There is no private-network agent.