SSL certificate monitoring
and expiry alerts

Watch the certificate your server actually serves. Status Harbor checks days-to-expiry, chain validity and hostname match every minute, and warns you weeks before a certificate lapses — public endpoints and internal ones alike.

Add an SSL monitorSee pricing

Why certificates still expire when renewal is automated

Automated renewal moved the failure, it did not remove it. cert-manager renews a Certificate resource on a schedule — and when the ACME HTTP-01 challenge stops routing, when an Ingress annotation drifts, when a TLS Secret gets recreated by a Helm upgrade, or when Let's Encrypt rate-limits the account, the renewal fails. cert-manager writes the failure to its own logs. Nobody reads cert-manager logs.

Six weeks later a certificate that everyone assumed was "handled by automation" expires, and the first signal anyone gets is a browser security warning on the production domain.

The only number that matters is the one the live endpoint serves. You can read it by hand:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

That one-liner works for a single host you remember to check. An SSL monitor runs the equivalent every minute, across every endpoint, and pages you when the count gets low.

What an SSL monitor checks

  • Days to expiry — the headline number. Set a threshold (30 days is a good default) and the monitor opens an incident the moment the certificate crosses it, then keeps reminding you until it is renewed.
  • Chain validity — the full chain the server presents. A missing intermediate certificate validates fine in your browser cache and fails for a fresh client. The monitor catches it.
  • Hostname match — a valid certificate that does not cover the hostname being requested is still a broken site. Common after a domain is added to an Ingress but not to the certificate's SAN list.
  • Live-served, not declared — the check inspects what the endpoint actually returns on a TLS handshake, not what a Kubernetes resource or a config file claims should be there.

Monitor internal and private certificates too

Internal certificates expire just as often as public ones, and they get watched less. An admin panel on *.internal.example.com, an mTLS service mesh endpoint, a private API behind a VPC — a public monitoring probe cannot reach any of them.

Run a Lighthouse agent inside your network and point SSL monitors at those endpoints. The agent probes from where the services live and reports back over a single outbound HTTPS connection, so internal certificates land on the same dashboard and the same alert channels as your public ones. Read more about private network monitoring.

Alerts that arrive in time to act

A certificate-expiry alert is only useful if it lands while there is still time to renew. Status Harbor checks SSL monitors every minute and routes alerts to Slack, Telegram, email or a webhook — the same channels as any other monitor, configured per monitor so a staging warning does not page the production on-call.

Because the warning repeats until the certificate is renewed, a notification missed in a busy channel does not turn into a missed renewal. The incident closes itself the minute a valid certificate is served.

Frequently asked questions

How early does Status Harbor warn before a certificate expires?

An SSL monitor reports days-to-expiry on every check. You set the threshold that opens an incident — 30 days is a sensible default, 14 days a hard floor. The warning fires once the certificate crosses your threshold and keeps firing until the certificate is renewed, so a single missed notification does not mean a missed renewal.

Why do certificates still expire when cert-manager handles renewals?

cert-manager renews the Certificate resource, but the renewal can fail quietly: an ACME HTTP-01 challenge that no longer routes, a rate limit, an Ingress annotation drift, a Secret that was recreated without the cert. cert-manager logs the failure; nobody reads cert-manager logs. An external SSL monitor checks the certificate actually served on the live endpoint, which is the only number that matters to a browser.

Can it monitor certificates on internal services behind a firewall?

Yes. Run a Lighthouse agent inside your network and point SSL monitors at internal Ingresses, admin panels or mTLS endpoints. The agent probes from inside, so you watch private certificates the same way you watch public ones — no inbound ports, no VPN.

Does it catch chain and hostname problems, not just expiry?

Yes. Each check validates the full chain the server presents, flags a missing intermediate certificate, and catches a hostname mismatch where the certificate is valid but does not cover the name being requested. Expiry is the common case; a broken chain after a deploy is the one that surprises people.

How often does it check?

SSL monitors run on the same 1-minute cadence as every other monitor. Certificates do not change minute to minute, but a frequent check means a renewal that swaps in a broken chain is caught within a minute of going live, not on the next daily cron.

Where do SSL alerts go?

The same channels as any other alert — Slack, Telegram, email or webhook. Each monitor routes to its own channel, so a staging certificate warning does not page the production on-call.

Never get surprised by an expired certificate

Add your first SSL monitor free — 5 monitors, no credit card.

Start monitoring free

Related