Skip to content

Certificate expiry risks

An expired certificate is among the most common completely preventable outages in IT. Nothing crashes and no hardware fails — the server keeps running and answers ping and TCP checks normally. Yet for users and integrations, the service is down.

What actually happens at expiry

  • Browsers hard-fail. The instant the validity window closes, every visit is interrupted by a full-page warning (Chrome's NET::ERR_CERT_DATE_INVALID, for example). The site's content never renders, most visitors leave, and on HSTS-protected sites the browser won't even offer a way to proceed.
  • API clients fail harder. Programs don't see warning pages — the TLS handshake simply errors out. Integrations, mobile apps, and payment callbacks stop working at once, and the failure often surfaces as a confusing error inside someone else's system, which makes it slow to diagnose.
  • The damage outlasts the fix. A browser warning screen reads as "this site is dangerous", and screenshots of it circulate longer than the outage itself.

Why teams miss renewals

  • Automation breaks silently. A DNS change breaks the ACME challenge, a firewall rule blocks the renewal endpoint, a scheduled job dies — and nothing complains until the certificate actually lapses.
  • Manual certificates depend on one person. A certificate bought for a year, tracked by a calendar reminder in the inbox of an employee who has since left.
  • Some certificates live outside the automation loop — on load balancers, appliances, mail gateways, and internal panels that were set up once and forgotten.
  • Renewed but never deployed. The new certificate was issued, but the service was never reloaded — so it keeps serving the old one until it expires.

The 30-day warning practice

The industry convention is to raise a warning 30 days before expiry, and the number is chosen deliberately. Automated 90-day certificates typically renew about 30 days out — so a warning that appears and stays open is itself the signal that automation has already missed its window. And for manually managed certificates, 30 days is enough to purchase, validate, and deploy a replacement even with change-control delays in the way.

What UpAll does

For every HTTPS monitor, UpAll reads the served certificate about once an hour and acts on the two moments that matter: 30 days before expiry it opens an Info incident, and on expiry — or when the certificate can't be read at all — a Degraded incident. Each incident emails all workspace staff, and each resolves automatically once a valid replacement certificate is served. Certificate incidents are always internal: they never appear in a client's portal and are never attributed to a client.

The full mechanics — what's read, where expiry shows in the console, how the incidents behave — are in SSL certificate monitoring; the background on chains and validity windows is in SSL/TLS certificates explained; how these incidents fit the severity ladder is in certificate incidents.