How to Set Up SSL Certificate Expiry Alerts

"It renews automatically, so I don't need to think about it" is the trap most teams fall into with SSL certificates. Auto-renewal through Let's Encrypt or another ACME client is genuinely reliable most of the time, but it isn't infallible, and when it fails, it tends to fail quietly. A DNS validation step can break after an unrelated DNS change. A renewal cron job can silently stop running. A load balancer with several nodes can renew the certificate on three of four and leave the fourth serving a stale one. None of these show up as an error anyone sees, until a customer hits the expired node and gets a browser warning.

An SSL monitor gives you a backstop independent of whatever renewal process you're already relying on. It checks the certificate directly, the same way a visitor's browser would, and alerts you if it's expired or getting close, regardless of what your renewal automation thinks happened. Here's how to set that up in Downdar.

What You Will Need

A Downdar account and API key, and the hostname of whatever you want to monitor. You don't need access to the certificate or private key, the check is entirely external, the same as any browser connecting to your site.

Creating an SSL Monitor

The /api/v1/monitors/create endpoint accepts a POST request specifying the monitor type and host:

curl -X POST https://downdar.com/api/v1/monitors/create \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "ssl", "name": "Main site certificate", "host": "www.example.com" }'

If you'd rather not script this, creating the monitor from your Downdar dashboard takes about the same amount of time, pick SSL as the check type and enter the hostname. Either way, Downdar checks the certificate on its regular interval and opens an incident if it's expired, invalid, or approaching its expiry date.

For a setup with several subdomains, each one needs its own monitor, a certificate check is per-hostname, the same way a browser's handshake is. If you're running a wildcard certificate across many subdomains, monitoring one representative hostname is usually enough, since they all share the same certificate and expiry date, but it's worth confirming that's actually true for your setup before assuming it.

What This Monitor Actually Checks

The check connects to the host, completes a TLS handshake, and inspects the certificate that comes back: whether it's currently valid, what domain it's issued for, and how many days remain until expiry. It's the same information SSL Labs' manual test surfaces in more depth, but checked automatically on a schedule instead of only when you remember to look.

It's worth being clear about scope: this confirms the certificate itself is valid and not expiring soon, it doesn't audit cipher suites, protocol versions, or configuration quality the way a deep security scan does. For that kind of one-off audit, a tool built specifically for it is still the better choice. What this monitor is for is the ongoing, boring, easy-to-forget part: knowing the certificate hasn't quietly expired or gone invalid since the last time anyone looked.

Configuring Alert Channels

By default, a new monitor alerts through your account's default channel. To route certificate alerts somewhere specific, pass alert_channel_keys when creating the monitor:

curl -X POST https://downdar.com/api/v1/monitors/create \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "ssl", "name": "Main site certificate", "host": "www.example.com", "alert_channel_keys": ["slack-eng-alerts"] }'

A certificate that's about to expire usually isn't a five-alarm emergency the moment the alert fires, there's normally still time to fix it, which makes it a reasonable candidate for a channel your team checks daily rather than one reserved for active incidents. Just make sure it's a channel someone actually reads regularly, an alert sitting unread until the certificate has already expired defeats the purpose.

Checking Monitor Status Programmatically

To pull a certificate monitor's current state into your own tooling, the /api/v1/monitors/status endpoint returns just the essentials.

curl -X POST https://downdar.com/api/v1/monitors/status \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"guid": "your_monitor_guid"}'   # Response includes "status": "up", "warn", "down", or "paused"

This is useful for surfacing certificate health on an internal dashboard, or as a pre-deploy check, confirming nothing's about to expire before you ship, without needing to log into Downdar directly.

Get Started

Set up a monitor for every public-facing hostname with its own certificate, it takes about as long as checking one manually on SSL Labs, except you only have to do it once.