How to Monitor SSL Certificate Expiration (and Why It Matters)

Published April 23, 2026 · 9 min read

Every developer has lived through it: a Slack message at 3am, a Twitter thread of angry users, a status page going red. The cause? An SSL certificate quietly expired overnight. The fix takes ten minutes. The damage to user trust takes weeks to repair.

This guide explains why TLS certificate expiration is one of the most common, most preventable causes of outages in 2026, what you should actually be monitoring, and how to set up automated checks that catch problems before your users do — all from your iPhone.

Why SSL Certificate Expiry Causes Real Outages

When a TLS certificate expires, browsers display a full-page security warning. Chrome, Safari, and Firefox all treat this as a hard failure: there is no easy "click through" path for normal users. Search engines may de-rank the site. Mobile apps that pin certificates or validate the chain refuse to connect. Webhooks from third-party services start failing. APIs your customers depend on return TLS handshake errors.

The technical recovery is trivial. Renew the certificate, deploy it, reload the web server. But the certificate is rarely the only thing that breaks. Caches need flushing. Mobile clients with old session tokens need to re-authenticate. Status page incidents need to be written and broadcast. Customer support tickets queue up. The blast radius from a five-minute oversight can occupy a team for an entire day.

The Three Failure Modes You Need to Catch

Certificate monitoring is not just about expiration dates. There are three distinct failure modes worth catching:

1. The Cert Will Expire Soon and Nobody Renewed It

This is the classic case. A certificate was issued 12 months ago, the person who managed it left the company, the renewal calendar reminder was set on someone's personal Gmail. Nobody is watching the clock.

2. The Cert Was Renewed but the New One Is Not Being Served

You ran certbot renew. It reported success. You moved on. What you missed: nginx was not reloaded, so it is still serving the old certificate from memory. Or the new cert was deployed to one load balancer node but not the other. Or a CDN is caching the old chain.

This failure mode is insidious because your renewal automation thinks everything is fine. The only way to catch it is to check the certificate that is actually being served, from outside your infrastructure.

3. The Cert Is Valid but Misconfigured

The chain is incomplete (missing intermediate). The hostname does not match a SAN. The signature algorithm is SHA-1 (deprecated). The key length is RSA-1024 (insecure). The protocol negotiated is TLS 1.0 (rejected by modern clients). The certificate is technically valid, but real users still cannot connect.

What to Monitor for Each Certificate

A useful certificate monitor checks all of the following on every poll:

• Days until expiry — the headline number, but not the only one
• Issuer — alerts if the CA changes unexpectedly (could indicate misconfiguration)
• Subject and SANs — confirms the cert covers the hostname being checked
• Key algorithm and size — flags weak keys (RSA < 2048, missing ECDSA)
• Signature algorithm — flags SHA-1 and other deprecated algorithms
• Negotiated TLS version — flags TLS 1.0/1.1, confirms 1.2+ is offered
• Chain completeness — missing intermediates fail on Android and older clients
• Hostname match — the CN or a SAN must match the requested hostname

How Often Should You Check?

For production services, every 6 hours is the sweet spot. It is frequent enough to catch a renewal that silently failed, infrequent enough to avoid hammering your endpoints. A TLS handshake adds no meaningful load — you are doing the same thing a normal browser does on first connect.

For ISO 27001-aligned environments, hourly checks provide a denser audit trail at negligible cost. For Let's Encrypt certs that auto-renew every 90 days, hourly checks are useful because they catch silent renewal failures sooner.

Setting Alert Thresholds That Actually Work

One alert at 14 days before expiry is not enough. People are on vacation. Notifications get dismissed without being read. The renewal process at your company might genuinely take three weeks because of an internal CSR approval workflow.

The pattern that works: multi-stage alerts. Get a notification at 30 days, again at 14, again at 7, and a daily reminder for the last 3 days. Each alert escalates the urgency. By the time the cert is one day from expiry, somebody has either renewed it or is being paged.

Step-by-Step: Set Up Cert Monitor on iPhone

1. Install PingKit from the App Store and subscribe to Guardian Plus ($4.99/month or $39.99/year).
2. Open the Monitor tab and tap into Cert Monitor.
3. Add your domains. Tap the + button and enter the hostname (e.g., api.example.com). Repeat for production, staging, and any internal services with TLS.
4. Set the check interval. 6 hours is a good default. Hourly if you prefer denser data.
5. Set the expiry threshold. Default 14 days. Increase to 30 if your renewals are manual.
6. Enable push notifications when prompted. Without this, you will not get the alert when it matters.
7. Test it. Add a domain with a known short-lived cert (Let's Encrypt staging is good for this) and confirm you see the days-until-expiry number update.

What About Free Online SSL Checkers?

Sites like SSL Labs are excellent for one-off configuration audits — they probe deeply, test cipher suites, check for known vulnerabilities. They are not a monitoring solution. You have to remember to visit them. They do not push notifications. They do not track historical changes. They do not generate audit-ready reports.

A monitoring tool runs continuously, alerts you when state changes, and keeps a history. Use SSL Labs for the initial deep audit when you bring a service online. Use a continuous monitor for everything that runs in production after that.

The Compliance Angle

If your organisation is working toward or maintaining ISO 27001, SOC 2, or similar certifications, certificate management is in scope. Auditors want to see evidence that you know which certificates are deployed, when they expire, and that you have a process for renewing them. A timestamped PDF inventory of every cert, with key length, signature algorithm, and expiry date, satisfies most auditors immediately.

PingKit Guardian Plus includes this PDF export. Tap Export in Cert Monitor and you have an audit-ready document on your phone. We covered the ISO 27001 mapping in detail in the ISO 27001 Certificate Evidence Guide.

Common Questions

Does monitoring add load to my servers?

No. A TLS handshake is the same operation a normal client does on first connect. At a 6-hour cadence, you are adding four handshakes per day per monitored hostname. That is invisible against any real production traffic.

What if my service is behind a private network?

Cert Monitor checks public endpoints from your device. For internal services, run the check from a machine inside your network. The PingKit Agent on Mac can monitor LAN endpoints continuously. For pure datacenter environments, dedicated infrastructure tools (Prometheus blackbox exporter, etc.) are better-suited.

Can I monitor wildcard certificates?

Yes. Add the specific hostname you want to verify (e.g., app.example.com) and Cert Monitor will check the certificate served for that hostname, which may be a wildcard. The SAN list will show the wildcard pattern and confirm the hostname is covered.

Conclusion

SSL certificate expiry is one of the most common preventable outages, and the cost of monitoring is essentially zero. Set up automated checks on every public-facing TLS endpoint you own, use multi-stage alerts so you have time to react, and verify the certificate that is actually being served — not just what your renewal automation thinks it deployed.

If you want all of this in one place, PingKit Guardian Plus does it from your iPhone. Add your domains once, set the schedule, and let it watch the certs while you focus on building.