Category scope

SSL monitoring, scoped to certificate state

“SSL monitoring” is used for at least four different jobs, and a tool that claims all of them usually does none of them well. ExpiryBeacon covers one: the state of the certificate a public endpoint presents.

Check a certificate Four jobs that share one name

Four jobs that share one name

Worth being explicit before you choose a tool, because these have different failure modes and different on-call owners.

Job	Covered here?
Certificate state — validity window, expiry, trust chain, covered names	Yes. This is the whole product.
Uptime and availability — is the endpoint answering, and with what status code	No. A certificate check that succeeds says nothing about your application.
TLS configuration grading — protocol versions, cipher suites, known weaknesses	Partly. The negotiated protocol and cipher for the check are reported, but there is no configuration score or vulnerability assessment.
Certificate inventory discovery — finding endpoints you forgot you had	No. Certificate Transparency discovery and wildcard inventory are not implemented; you add each endpoint yourself.

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.

The states a monitor can report

Healthy

Chain validates, expiry is beyond the monitor's warning window, and the last check completed normally.

At risk

Either the warning window has been reached or the chain no longer validates. Both need a person; neither is an outage yet.

Expired

The notAfter date has passed. Browsers are already refusing the connection.

Check failed

The handshake could not be completed. The last verified evidence is preserved and shown with its original timestamp rather than being overwritten.

How this sits next to uptime tooling

Certificate expiry has an unusual property among production risks: the exact failure time is known weeks in advance and printed on the certificate itself. That makes it a poor fit for the tools built around minute-by-minute polling and a good fit for a daily check with a long warning window.

It also means the two kinds of monitoring answer different questions. Uptime monitoring tells you something broke. Certificate monitoring tells you something is going to break on a specific date unless someone acts. Running ExpiryBeacon alongside an uptime service is the intended arrangement, not a workaround.

That scoping is why the daily schedule is a deliberate choice rather than a limitation to apologise for. Checking a 90-day certificate every 30 seconds does not shorten the renewal path.

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.

Not offered, and not planned before real usage

Multi-region checks and regional comparison.
Webhooks, Slack, Microsoft Teams, SMS, and paging.
Incident acknowledgement, escalation policies, and on-call rotation.
Team workspaces, shared monitor ownership, and audit logs.
Private-network monitoring through an installed agent.
Certificate Transparency discovery and bulk CSV import.

Questions about ssl monitoring

Is SSL monitoring the same as uptime monitoring?

No. ExpiryBeacon reports the state of the certificate an endpoint presents. It does not measure availability, response time, or status codes, and it should be run alongside an uptime tool rather than instead of one.

Does ExpiryBeacon grade my TLS configuration?

Not as a score. Each check reports the protocol version and cipher suite that were negotiated, but there is no configuration rating and no vulnerability scanning.

Can it find certificates I do not know about?

No. There is no Certificate Transparency search or wildcard inventory. Every endpoint is one you add yourself, up to 50 per account.

What protocols and ports are supported?

Direct TLS on ports 443, 8443, and 9443 against public hostnames. STARTTLS protocols such as SMTP and IMAP are not supported.