SSL certificate monitoring that verifies more than a date

The failure modes an expiry check misses

• A certificate that is trusted and unexpired but issued for the wrong name, so browsers reject it on a hostname you serve.
• A wildcard renewal that quietly dropped a SAN entry, breaking one subdomain and nothing else.
• A server holding the leaf certificate but no intermediate. Desktop browsers paper over it from cache; mobile clients and curl do not, so it looks fine to you and broken to half your users.
• A self-signed certificate installed during an emergency and never swapped back.
• A certificate not valid yet, because a clock or an automation ran ahead of itself.

Every one of those presents a certificate with a future expiry date, so a monitor that only reads the date reports green.

What the SSL probe actually does

Undownable connects on port 443, or whichever port you configure, captures the certificate the server presents, and runs three judgements in order.

Validity dates first. An expired certificate reports down with a precise message, "Certificate expired 3 days ago" rather than a generic handshake error, and one whose notBefore is in the future reports the date it becomes valid. That precision is why the capture connection runs with verification off: a verifying handshake against an expired certificate just fails, and you lose the reason.

Then the name. The probe collects the dNSName entries from the SAN extension, falling back to the subject common name when there are none, and matches your hostname with RFC 6125 rules. Wildcards match one leftmost label, so *.example.com covers foo.example.com but not a.b.example.com.

Finally the chain. A second handshake runs with full peer and peer-name verification on, catching self-signed certificates, untrusted issuers, and missing intermediates. Only a certificate that survives all three counts as healthy.

Warnings that escalate instead of going quiet

The classic renewal disaster is not a missing warning. It is a warning that arrived 30 days out, got filed under "next week", and was never repeated until the certificate expired at 2am on a Saturday.

Undownable escalates. Inside the warning window, which defaults to 30 days and is configurable per monitor, the result carries the threshold it has crossed: your configured window first, then 14 days, then 7, then 1. Each time the remaining validity reaches a tighter one, a fresh alert goes out.

Degraded is a warning, not an outage

A certificate expiring in nine days is not downtime: the site is serving and browsers are happy. Degraded has its own badge, it alerts, and it counts as up when uptime is computed, so a renewal you handled on time does not dent your monthly figure.

When the certificate is renewed and validity climbs back out of the window, the monitor returns to up and the episode closes with an all-clear. The escalation level resets for the next cycle.

Setting up a certificate monitor

• Create a monitor and choose the SSL certificate type.
• Enter the hostname. A bare host or a full https URL both work.
• Set the port if the service is not on 443: mail on 465, a TLS-fronted database, an admin panel on 8443.
• Set the warning window. The 30-day default suits a 90-day Let's Encrypt certificate; a one-year commercial certificate is often better at 45 or 60.
• Pick an interval. Certificates change slowly, so five-minute checks on the free plan are ample.
• Attach notification channels, or leave it unrouted to alert every team channel.

Certificate monitors run on the free plan alongside its other nine, with 30 days of history, a status page, and every alert channel: email, ntfy, Telegram, Slack, Discord, and webhooks. Delivery is exactly-once, which matters here because escalation deliberately sends several alerts about one certificate. Pro adds 50 monitors, one-minute checks, unlimited status pages and members, custom domains, and a year of history, for a flat per-team price with no per-monitor fees, after a 14-day trial with no card.

Questions people ask