[{"data":1,"prerenderedAt":358},["ShallowReactive",2],{"blog-\u002Fblog\u002Fhow-to-monitor-ssl-certificate-expiration":3},{"id":4,"title":5,"author":6,"body":7,"category":343,"date":344,"description":345,"extension":346,"faqs":347,"image":348,"meta":351,"navigation":352,"path":353,"readingTime":354,"seo":355,"stem":356,"__hash__":357},"blog\u002Fblog\u002Fhow-to-monitor-ssl-certificate-expiration.md","How to Monitor SSL Certificate Expiration","Monitoristic Team",{"type":8,"value":9,"toc":324},"minimark",[10,14,27,30,35,38,67,70,74,77,94,107,114,125,128,147,158,162,167,179,183,190,194,218,222,225,229,242,246,273,277,283,286,290,308],[11,12,13],"p",{},"There's a category of outage that is completely predictable, entirely preventable, and yet still takes down real sites every single day: the expired SSL certificate.",[11,15,16,17,21,22,26],{},"It's not a hack, a traffic spike, or a server crash. It's a date passing. One moment your site loads fine; the next, every visitor gets a full-screen browser warning — ",[18,19,20],"em",{},"\"Your connection is not private\""," — and bounces. Search crawlers see it too. And because nothing \"broke,\" your server keeps happily returning ",[23,24,25],"code",{},"200 OK"," to anything that ignores the certificate, so a basic check can miss it entirely.",[11,28,29],{},"The good news: expiry is the easiest outage in the world to prevent, because it announces itself in advance. You just have to be watching.",[31,32,34],"h2",{"id":33},"why-expired-certificates-are-so-damaging","Why expired certificates are so damaging",[11,36,37],{},"An SSL\u002FTLS certificate is what powers the padlock and HTTPS. When it expires, browsers don't show a subtle warning — they hard-block the page with an interstitial that most users will never click through. The effect is total:",[39,40,41,49,55,61],"ul",{},[42,43,44,48],"li",{},[45,46,47],"strong",{},"Every visitor is turned away",", not just some. It's a 100% outage for anyone on a modern browser.",[42,50,51,54],{},[45,52,53],{},"The warning is scarier than a normal error."," \"Not private\" reads as \"you've been hacked\" to a non-technical visitor. Trust damage outlasts the outage.",[42,56,57,60],{},[45,58,59],{},"APIs and integrations break too."," Any client that validates certificates (most do) will refuse to connect — so your mobile app, webhooks, and server-to-server calls fail alongside the website.",[42,62,63,66],{},[45,64,65],{},"SEO takes a hit."," Crawlers that hit certificate errors can drop pages from the index if it persists.",[11,68,69],{},"And it almost always happens at the worst time, because certificates expire on a fixed schedule that has nothing to do with your calendar — a weekend, a holiday, the middle of the night.",[31,71,73],{"id":72},"why-auto-renewal-isnt-a-guarantee","Why auto-renewal isn't a guarantee",[11,75,76],{},"\"I use Let's Encrypt with auto-renewal, so I'm fine.\" This is the single most common reason people get burned. Auto-renewal is great — until the renewal silently fails. Real-world causes we see constantly:",[39,78,79,82,85,88,91],{},[42,80,81],{},"The renewal cron job stopped running, or the server it ran on was retired.",[42,83,84],{},"A firewall or config change broke the HTTP-01\u002FDNS-01 validation challenge.",[42,86,87],{},"The domain's DNS changed and the validation can no longer complete.",[42,89,90],{},"A load balancer or CDN is serving an old certificate even though the origin renewed.",[42,92,93],{},"The renewal succeeded but nothing reloaded the web server to pick up the new certificate.",[11,95,96,97,100,101,106],{},"In every one of these cases, automation ",[18,98,99],{},"thinks"," it's handling things while the clock keeps ticking. The only way to know the certificate your visitors actually receive is valid is to check the live certificate from the outside — which is exactly what monitoring does. (This is why ",[102,103,105],"a",{"href":104},"\u002Fblog\u002Fhow-to-monitor-website-uptime","external monitoring beats internal assumptions"," across the board.)",[31,108,110,111,113],{"id":109},"a-plain-200-ok-check-is-not-enough","A plain ",[23,112,25],{}," check is not enough",[11,115,116,117,119,120,124],{},"Here's the subtle part. Some uptime checks connect in a way that ignores certificate validity, or only care about the HTTP status code. A server with an expired certificate can still return ",[23,118,25],{}," to a client that doesn't verify the chain — so a naive check stays green while real browsers are blocked. This is another flavor of the ",[102,121,123],{"href":122},"\u002Fglossary\u002Fuptime-monitoring","silent failure"," problem: the check passes, the users don't.",[11,126,127],{},"Good SSL monitoring does two distinct jobs:",[129,130,131,137],"ol",{},[42,132,133,136],{},[45,134,135],{},"Validate the live certificate"," — confirm it's present, trusted, matches the hostname, and isn't expired.",[42,138,139,146],{},[45,140,141,142,145],{},"Warn you about ",[18,143,144],{},"upcoming"," expiry"," — alert days in advance, not at the moment it breaks.",[11,148,149,150,153,154,157],{},"That second point is the whole game. An alert ",[18,151,152],{},"after"," expiry is just downtime. An alert ",[18,155,156],{},"before"," expiry is a non-event you fix in five minutes.",[31,159,161],{"id":160},"how-to-monitor-ssl-certificate-expiration","How to monitor SSL certificate expiration",[163,164,166],"h3",{"id":165},"_1-monitor-over-https-from-the-outside","1. Monitor over HTTPS, from the outside",[11,168,169,170,173,174,178],{},"Point a monitor at your ",[23,171,172],{},"https:\u002F\u002F"," URL so it makes a real TLS connection to your live site — the same handshake a browser does. This catches not just expiry but also misconfigured chains, hostname mismatches, and a CDN serving a stale certificate. Checking from outside your network is what makes it trustworthy; you're seeing what your visitors see. See ",[102,175,177],{"href":176},"\u002Fdocs\u002Fsetting-up-monitor","setting up a monitor"," for the basics.",[163,180,182],{"id":181},"_2-get-warned-days-in-advance","2. Get warned days in advance",[11,184,185,186,189],{},"The most important setting is the ",[45,187,188],{},"expiry warning threshold"," — how many days before expiry you want to be told. A sensible default is 14 days, with a second nudge at a few days out. That window gives you time to renew calmly instead of firefighting. Treat the alert as routine maintenance, not an incident.",[163,191,193],{"id":192},"_3-cover-every-hostname-and-subdomain","3. Cover every hostname and subdomain",[11,195,196,197,200,201,204,205,208,209,212,213,217],{},"Certificates are per-hostname (or per-wildcard). It's easy to renew ",[23,198,199],{},"example.com"," and forget ",[23,202,203],{},"api.example.com",", ",[23,206,207],{},"status.example.com",", or ",[23,210,211],{},"www",". Monitor each hostname that has its own certificate — including your status page if it's on a ",[102,214,216],{"href":215},"\u002Fglossary\u002Fstatus-page","separate domain",". One forgotten subdomain is still a full outage for whatever lives there.",[163,219,221],{"id":220},"_4-dont-forget-internal-and-machine-endpoints","4. Don't forget internal and machine endpoints",[11,223,224],{},"The certificates most likely to lapse are the ones no human visits: an API subdomain, a webhook receiver, an admin panel, an internal tool. No one notices the padlock there until an integration silently stops connecting. Monitor those too — they break the same way, just more quietly.",[163,226,228],{"id":227},"_5-route-the-alert-somewhere-youll-actually-see-it","5. Route the alert somewhere you'll actually see it",[11,230,231,232,236,237,241],{},"An expiry warning is useless in an inbox you don't read. Send it to a channel you watch — a ",[102,233,235],{"href":234},"\u002Fblog\u002Fhow-to-set-up-telegram-alerts-for-downtime","Telegram alert"," to your phone or a ",[102,238,240],{"href":239},"\u002Fblog\u002Fhow-to-set-up-webhook-alerts-for-downtime","webhook"," into your team's channel — so a 14-day warning actually reaches the person who can renew.",[31,243,245],{"id":244},"a-simple-ssl-monitoring-checklist","A simple SSL monitoring checklist",[39,247,248,254,257,260,267,270],{},[42,249,250,251,253],{},"Monitor every public hostname over ",[23,252,172],{},", from outside your network.",[42,255,256],{},"Set an expiry warning at ~14 days, with a second reminder a few days out.",[42,258,259],{},"Include subdomains, API hosts, status pages, and internal tools — anything with its own certificate.",[42,261,262,263,266],{},"Don't rely on auto-renewal alone; verify the ",[18,264,265],{},"live"," certificate, not the renewal job's logs.",[42,268,269],{},"Send warnings to a channel you check daily, not a forgotten mailbox.",[42,271,272],{},"When a warning fires, renew and confirm the new certificate is actually being served (reload the server \u002F purge the CDN).",[31,274,276],{"id":275},"the-bottom-line","The bottom line",[11,278,279,280,282],{},"An expired certificate is the rare outage you can see coming weeks away. The teams that get caught aren't careless — they're trusting automation that failed quietly, or a ",[23,281,25],{}," that lied. Monitoring the live certificate from the outside, with a warning days before expiry, turns a 100% outage and a trust-shattering browser warning into a calm five-minute renewal nobody else ever notices.",[11,284,285],{},"That's the entire goal of monitoring: move every failure you can from \"found out from an angry user\" to \"handled before it mattered.\"",[31,287,289],{"id":288},"related-reading","Related reading",[39,291,292,297,303],{},[42,293,294],{},[102,295,296],{"href":104},"How to Monitor Website Uptime",[42,298,299],{},[102,300,302],{"href":301},"\u002Fblog\u002Fwhat-to-do-when-your-website-goes-down","What to Do When Your Website Goes Down",[42,304,305],{},[102,306,307],{"href":176},"Setting Up a Monitor",[11,309,310,311,204,315,319,320,323],{},"New to the terminology? See ",[102,312,314],{"href":313},"\u002Fglossary\u002Fssl-monitoring","SSL monitoring",[102,316,318],{"href":317},"\u002Fglossary\u002Fdowntime","downtime",", and ",[102,321,322],{"href":122},"uptime monitoring"," in our glossary.",{"title":325,"searchDepth":326,"depth":326,"links":327},"",2,[328,329,330,332,340,341,342],{"id":33,"depth":326,"text":34},{"id":72,"depth":326,"text":73},{"id":109,"depth":326,"text":331},"A plain 200 OK check is not enough",{"id":160,"depth":326,"text":161,"children":333},[334,336,337,338,339],{"id":165,"depth":335,"text":166},3,{"id":181,"depth":335,"text":182},{"id":192,"depth":335,"text":193},{"id":220,"depth":335,"text":221},{"id":227,"depth":335,"text":228},{"id":244,"depth":326,"text":245},{"id":275,"depth":326,"text":276},{"id":288,"depth":326,"text":289},"Guide","2026-06-11","An expired SSL certificate takes your whole site down with a scary browser warning — and it always happens at the worst time. Here's how to catch it days before it bites.","md",null,{"src":349,"alt":350},"\u002Fblog\u002Fblog-how-to-monitor-ssl-expiration.webp","Monitoring SSL certificate expiration before it causes downtime",{},true,"\u002Fblog\u002Fhow-to-monitor-ssl-certificate-expiration",7,{"title":5,"description":345},"blog\u002Fhow-to-monitor-ssl-certificate-expiration","5KANHKYYqiEG5f8M-Beh12rifviY-MjavjmRV7sXJSE",1781167396353]