Updated 25 October 2026 · By the Upcertain team
What is checked
- Expiry. How many days the certificate has left.
- Hostname. The certificate must cover the name you monitor.
- Chain. The certificate must chain to a trusted root, with every intermediate served.
An expired certificate, a hostname mismatch or a broken chain fails the check and opens an incident like any other outage, with the reason in the alert.
Warnings before expiry
Warnings arrive 30, 14 and 7 days before expiry by default. You can pick up to five days between 1 and 90, for example 45, 21 and 3 if your renewals go through a slow approval. Each warning names the host, the expiry date and the issuer, and goes to the channels that subscribe to SSL events.
| Monitor | What fails it | Expiry warnings |
|---|---|---|
| HTTPS website or API | The page itself, plus an invalid certificate | Yes |
| SSL certificate | Only the certificate | Yes |
Every HTTPS website monitor already does both. Use a separate SSL monitor for hosts you do not want to watch for uptime, or where you want certificate warnings to go to a different channel than outages.
Why automated renewals still fail
Certificates from Let's Encrypt and other automated issuers renew on their own until something changes. A DNS record moves, or a firewall blocks the validation request. A load balancer keeps serving the old certificate after the new one is issued, or a host behind a CDN is forgotten. An expiry warning 30 days out turns each of those into a calm fix instead of an outage. More in why certificate expiry still causes outages.
Alert routing
Each alert channel chooses which events it receives: down, recovery and SSL. A common setup sends outages to the on-duty Slack channel and SSL warnings to the email address of whoever manages certificates.