SSL Certificate Monitoring: Expiry, Chains and Alerts

SSL certificate monitoring is a scheduled check that reads the certificate your server presents and alerts you before it stops validating. It watches four things: the expiry date, the chain back to a trusted root, the hostname match, and the protocol the handshake settles on. Expiry is the famous failure. The other three cause the longer outages.

What does ssl certificate monitoring actually check?

A probe opens a TLS connection, completes the handshake, and reads every certificate the server sends. From that it can answer four questions without touching your application at all. Each one has a different failure mode and a different amount of warning.

What the probe reads	Typical failure	Warning you get
Leaf expiry date	Renewal cron stopped running	Weeks, if you ask for it
Intermediate and root chain	Server sends leaf only after a deploy	None, it breaks instantly
Subject alternative names	New hostname added, cert not reissued	None
Protocol and cipher	TLS 1.0 disabled at a load balancer	None

Only the first row gives you time. The rest are cliff edges, which is why a calendar reminder is not a substitute for a check that runs every minute.

Why the warning window got shorter in 2026

Certificate lifetimes are shrinking on a published schedule. The CA/Browser Forum adopted ballot SC-081v3 in April 2025. It caps publicly trusted TLS certificates at 200 days from 15 March 2026, then 100 days from 15 March 2027, then 47 days from 15 March 2029. As of September 2026 the 200-day cap is the one in force.

That changes the arithmetic. A 30-day warning was a tenth of a 398-day certificate and is now more than a seventh of a 200-day one. Let's Encrypt has issued 90-day certificates since the start and recommends renewing at 60 days, which leaves a 30-day tail. Shorter lifetimes are also the argument for automating renewal, because ssl certificate monitoring tells you a renewal failed and cannot perform it for you.

We prefer a two-stage ladder instead of one threshold: a quiet notification at 21 days and a real alert at 7.

Setting up ssl certificate monitoring

Uptime Room has a dedicated ssl monitor type that does the handshake and nothing else, so it fails for certificate reasons only. Create one per hostname you serve, including the ones nobody visits. The certWarnDays field sets how early the monitor starts warning.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "www cert",
    "type": "ssl",
    "target": "https://example.com",
    "intervalSec": 300,
    "regions": ["london", "singapore"],
    "certWarnDays": 21
  }'

Five minutes is plenty here. A certificate does not change between checks, and a tighter interval buys nothing except probe traffic. Route the warning somewhere slow and the expiry somewhere loud by creating two destinations at the channels endpoint, which lives at /api/v1/channels.

The chain breaks more often than the leaf

Most teams that get burned did renew on time. What they missed is that a server has to send the intermediate certificate as well as its own. Browsers often paper over a missing intermediate by fetching it themselves, so the site looks fine on your laptop while curl, a mobile app and a payment webhook all fail.

Check what the server actually sends, not what a browser reconstructs.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null \
  | grep -E "^(subject|issuer)="

Two or more certificates should come back. One means the chain is incomplete and you are relying on client-side repair. We tested this against a staging host that had just moved behind a new proxy. The browser showed a padlock. The ssl check failed on chain verification from both regions inside the same minute.

Wildcards, SANs and the hosts you forgot

A wildcard certificate for *.example.com covers one label only. It matches api.example.com and does not match eu.api.example.com or the bare apex. Teams discover this when a new environment gets a deeper name and the handshake starts failing for a subset of clients.

Subject alternative names have the opposite problem. They are explicit, which is good, and they are edited by hand, which is not. A reissue that drops a name nobody remembers adding breaks exactly one integration, usually a partner callback with no human watching it.

Build the check list from the certificate rather than from memory. This prints every name the live certificate actually covers.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

Create a monitor for each name that resolves. A name on the list that no longer resolves is a cleanup task for the next reissue. A name that resolves but is missing from the list is an outage waiting for its first visitor.

How many regions should the check run from?

Two, and for the same reason any external check uses two. A single probe that cannot complete a handshake may be looking at a local network fault rather than a bad certificate. Confirmation across regions is the difference between an alert and a guess, and the mechanics are covered in cross-region quorum confirmation.

Regions matter for a second reason with TLS. A content delivery network can serve a different certificate from a different edge, so a renewal that propagated to Europe may not have reached Asia. Six probe regions are available as of September 2026, and the egress addresses for each one are published on the probe IPs page if your edge filters by source.

What the outside view cannot see

External ssl certificate monitoring reads what a public client is served, and only that. A certificate bound to an internal listener, an admin port behind a VPN, or a service mesh sidecar is invisible to a probe on the internet. Those need a check that runs inside the network, and the layered version of that argument is in black box monitoring.

The handshake is also only one leg of a request. An HTTP-family check reports a full timing waterfall: DNS resolution, TCP connect, TLS handshake, TTFB and content download. A slow handshake therefore shows up as its own number rather than as a vague slowdown. That matters when a certificate authority's OCSP responder is the thing having a bad day.

Common mistakes

Watching the apex and forgetting everything else. Mail hosts, API subdomains, the staging environment and any vanity domain that redirects all present certificates. Each one needs its own check, and the forgotten redirect domain is the classic 3am page.

Treating a cert alert as the same severity as a down alert. An expiry warning is a task with a deadline. Routing it to the same channel as an outage trains people to ignore both, which is the mechanism described in alert fatigue.

Alerting on the certificate but not on the renewal job. The certificate check tells you the outcome weeks later. A heartbeat on the renewal job tells you the same night it failed, and the two together close the gap between a silent cron failure and a visible expiry warning.

Assuming TLS monitoring covers revocation. A handshake succeeds against a revoked certificate unless the client checks OCSP or a CRL and enforces the answer. Revocation is a separate question from validity, and RFC 8446 leaves enforcement to the client.

Good ssl monitoring is boring by design: it should tell you about a renewal three weeks early and never again. Create one certificate check per hostname you serve, warn at 21 days, page at 7, and confirm from two regions before anyone gets woken up. With the 200-day cap in force as of September 2026, ssl certificate monitoring is now a standing requirement rather than an annual chore. Start with the redirect domain nobody remembers owning, on the free plan.