There is no grace period on an expired certificate. The moment the date passes, browsers put a full-page security warning in front of your site and API clients refuse the connection outright. This page assumes it has already happened and you want it fixed.
From $5 a month · No check quotas · Set up in under a minute
How do I fix an expired SSL certificate?
Reissue the certificate, deploy it to every server that terminates TLS, restart or reload the web server, and then verify from outside your own network — because the most common reason a site stays broken after a renewal is that the new certificate was issued but never actually served. Then work out which of the five silent failures caused it, or it will happen again in ninety days.
An expired certificate is the most complete kind of trust failure. The site is running, the server is healthy, every uptime check passes — and no visitor can reach it without clicking through a warning that tells them your site may be dangerous. Most of them will not click through.
The repair itself is usually quick. What takes the time is discovering that the renewal you thought had run did run, and produced a certificate that is sitting on disk somewhere the web server never looked.
In order. Do not skip the last step — it is the one people skip.
Open the site in a browser and read the error. "Certificate has expired" is unambiguous. If the message mentions an unknown issuer or an incomplete chain instead, the problem may be an intermediate rather than your own certificate, which is a different fix. Check the expiry date the server is actually serving rather than the date you remember issuing.
With Let's Encrypt or any ACME client, run the renewal manually rather than waiting for the timer — the timer is what failed. With a commercial certificate, reissue through the vendor. This step is usually minutes.
This is where recoveries go wrong. If you run several web servers behind a load balancer, a CDN, or a reverse proxy, each of them may hold its own copy. A certificate renewed on one node leaves the others serving the expired one, so the site appears broken for some visitors and fine for others.
Nginx, Apache and most proxies read the certificate at startup. A new file on disk changes nothing until the process reloads. A great many "the certificate is renewed but the site is still broken" reports are this and nothing else.
Your browser may have cached the old certificate, and your network may reach a different node than the public does. Check from an external tool, an incognito window on mobile data, or a monitoring service. Confirm the expiry date the public actually receives.
Renewal working ninety-nine times is exactly what makes the hundredth failure invisible.
The certificate was issued correctly and is sitting in a directory. Nothing copied it to the server that serves traffic, or nothing reloaded that server. The renewal log says success, and the site is down.
A cron entry removed during a migration, a systemd timer disabled, a container rebuilt without the job. There is no error because nothing ran. This is the failure mode a heartbeat monitor exists to catch.
ACME renewal has to prove you still control the domain. A changed DNS provider, a removed TXT record, a redirect added in front of the HTTP challenge path or a firewall rule can all break validation while everything else looks normal.
An expired intermediate certificate produces browser errors even though your own certificate is perfectly valid. Most monitoring reads only the leaf certificate — ours included — so this class of failure is frequently invisible until it breaks.
Let's Encrypt no longer sends expiration emails, which for many small sites was the only safety net behind the automation. If nothing replaced it, the first notification is a customer.
More than the warning page, and some of it silently.
Browsers show an interstitial that most visitors will not click past — and for sites using HSTS, there is no click-through option at all, so the site is simply unreachable until the certificate is fixed.
API clients and server-to-server integrations are worse, because they fail hard and quietly. Webhooks stop arriving, payment callbacks fail, mobile apps lose their backend, and none of it produces a user-visible warning that anyone will report to you. It is common for the certificate to be fixed within the hour and for a broken integration to be discovered days later.
| Affected | What happens | Do you find out? |
|---|---|---|
| Browser visitors | Full-page security warning | Only if somebody tells you |
| HSTS-enabled sites | No click-through option at all | Site simply unreachable |
| API and webhook clients | Connection refused, hard failure | Often not for days |
| Mobile apps | Backend calls fail | Through app reviews, eventually |
| Uptime monitoring | Often still reports HTTP 200 | No — this is the trap |
Four things, and only the first is monitoring.
Read the certificate from outside, the way a visitor receives it. A renewal log tells you what was issued; only an external check tells you what is actually being served, which is the thing that matters.
Not the time it takes when everything works. If a renewal needs a purchase order or someone else's approval, seven days is not a warning, it is a countdown. Our window is configurable from 1 to 60 days for exactly this reason.
A monitor pointed at a host that no longer resolves reports nothing and looks healthy. If your tool cannot tell you that the check itself broke, you have a monitor that can quietly stop being one.
If renewal runs as a scheduled job, monitor the job. A cron that stops running produces no error and no failed request — a heartbeat is the only thing that notices.
Restore a site after its TLS certificate has expired.
Read the browser error. Check the expiry date the server is actually serving, not the one you expect.
Run the ACME client manually, or reissue through your certificate vendor.
Every web server, load balancer, proxy and CDN edge that holds its own copy.
The new file changes nothing until the process re-reads it.
Use an external check or mobile data. Your own network and browser cache can both lie to you.
A certificate monitor with a warning window, and a heartbeat on the renewal job if one exists.
Typically about 30 minutes from start to finish.
Uptime monitors, watched pages and heartbeats each get their own allowance, so adding a page watch never costs you a monitor. SSL and domain checks ride along with the monitor they belong to and use nothing extra.
| Plan | Monitors | Watched pages | Heartbeats | Fastest interval | Alert channels | Price |
|---|---|---|---|---|---|---|
| Free | 1 | 1 | 1 | Every 30 minutes | 1 email address | $0 |
| Founding Member first 20 only | 25 | 25 | 25 | Every 5 minutes | Email + webhook & chat | $5/mo |
| Basic | 10 | 10 | 10 | Every 10 minutes | Email + webhook & chat | $8/mo |
| Growth | 50 | 50 | 50 | Every 5 minutes | Email + webhook & chat | $19/mo |
| Pro | 100 | 100 | 100 | Every 60 seconds | Email + webhook & chat | $34/mo |
Annual billing is cheaper on every paid tier. The pricing page is the authoritative list.
Every recorded change is compared word by word and kept with a before-and-after image. This is the real output, shown with worked example data.
Price fell from $49 to $39, and an annual discount was added.
The item is available again and the basket button returned.
A new subprocessor was added in another jurisdiction.
The free plan sends to one email address. Every paid plan adds the chat and webhook channels below, with 2 to 10 destinations depending on the plan. However many alerts you receive, the price does not change — nothing here is metered or charged per alert.
There are no voice calls and no SMS. If a phone call at 3am is a hard requirement, say so before you subscribe — we would rather tell you now than refund you later.
No. Validity ends at the second stated in the certificate. Browsers reject it immediately — there is no tolerance window the way there is with domain registration.
Usually by clicking through a warning, which most will not do. If your site sends HSTS headers, browsers will not offer a click-through at all and the site is simply unreachable until the certificate is replaced.
Almost always one of two things: the web server has not been reloaded so it is still serving the old certificate from memory, or the new certificate was deployed to one server and not to the others behind your load balancer or CDN.
The reissue is usually minutes with an ACME client. Deployment and verification are what take time, particularly across multiple servers. Expect under an hour if you have access to everything.
Most commonly the renewal job stopped running, domain validation broke, or the certificate was issued but never deployed. Check the renewal log first — if it shows success, the problem is deployment, not issuance.
Indirectly and quickly. Users bouncing off a security warning is a strong negative signal, and crawlers encountering TLS errors may reduce crawling. The larger cost is usually lost traffic and trust during the outage itself.
Often not. Many uptime checks still report a healthy response, and some tools ignore certificate validation entirely so that they can keep checking. Certificate expiry needs its own monitor with its own warning window.
Then your own certificate is fine and the chain is broken, which produces a different browser error. Fixing it usually means updating the intermediate bundle your server sends. Note that most monitoring tools, ours included, read only the leaf certificate and will not warn you about this.
Last updated August 4, 2026 · Written by Amit Gupta, founder of MonitoringDaddy
Certificate monitors with windows from 1 to 60 days, plus alerts when a certificate has already expired or the check itself fails. From $5 a month.