Monitor SSL Certificate Expiry From Your Phone
Let's Encrypt certificates last 90 days and renew automatically, which has quietly made expiry outages more likely rather than less. Automation removes the task from your attention until the automation itself breaks, and when it breaks it does so silently: a renewal hook fails, a firewall rule blocks the challenge, a DNS record moves, and nothing complains until browsers start refusing to load the site. The useful habit is not trusting that renewal is configured. It is periodically looking at the actual expiry date on the actual certificate the server is serving.
Written by the GateShell team at Hefty Innovations
Step by step
- 1
Check the served certificate, not the config
The distinction matters more than it sounds. Certbot can renew a certificate on disk perfectly while the web server continues serving the old one, because nothing reloaded it. A configuration that looks correct and a certificate file with a future expiry date are both consistent with an outage tomorrow. The only thing that settles it is the expiry date on the certificate being presented on the wire. GateShell's certificate monitor reads what the server is actually serving, per host, and shows the remaining days.
- 2
Look across servers, not one at a time
Expiry problems cluster: the same misconfigured renewal hook usually exists on every server built from the same image, and the certificate you forget is never the one on the server you log into daily. Reviewing expiry across all your servers in one list turns this from something you remember to check into something you notice. The one showing 8 days when everything else shows 60 is the interesting row.
- 3
Treat anything under 30 days as needing an explanation
With 90-day certificates, renewal is attempted well before expiry, so a healthy certificate should rarely be seen with under 30 days remaining. A certificate at 20 days is not yet an emergency, but it is evidence that automated renewal has already failed at least one attempt. This is the window where the fix is calm and unhurried, which is the entire reason to look before you are forced to.
- 4
Find out why renewal did not happen
Check the renewal timer or cron entry actually ran, then read its output. The common causes are dull and repeatable: the HTTP-01 challenge could not reach the server because a firewall rule changed, the DNS record used for a DNS-01 challenge moved, the web root moved after a deploy, or a post-renewal reload hook exited non-zero and left the new certificate unloaded. The Certbot and Cron dashboards show the schedule and recent results, so you can tell a job that failed from one that never ran — which point at completely different fixes.
- 5
Renew, then confirm the server is serving the new one
After forcing a renewal, reload the web server and check the expiry date again from the outside. This is the step that closes the loop, and skipping it is how the reload-hook failure survives a renewal. If the file on disk says 90 days and the served certificate still says 8, the certificate renewed and the server never picked it up.
- 6
Get told rather than remembering to look
Anything that depends on you checking periodically will eventually be forgotten, usually during the week you are busiest. The optional self-hosted agent collects certificate state on a schedule alongside its other checks and can alert you, so the 30-day threshold produces a notification rather than depending on your attention. It runs on your own server and keeps its history there.
Frequently asked questions
Why do certificates expire when I have automated renewal?+
Because the renewal failed and nothing told you. The common causes are a blocked ACME challenge after a firewall change, a moved DNS record, a web root that moved during a deploy, or a post-renewal reload hook that failed so the new certificate was never loaded. Automation removes the task from your attention, which is exactly why silent failure is so effective.
What is a sensible warning threshold?+
Thirty days is a good default for 90-day certificates. Renewal is normally attempted around the 30-day mark, so seeing fewer than 30 days remaining means at least one attempt has already failed. It gives you weeks of margin while still being a meaningful signal rather than constant noise.
Does this need an agent installed on the server?+
No. Checking expiry works over your existing SSH connection with no additional software. The optional self-hosted Go agent is only needed if you want scheduled checks and push alerts instead of looking on demand.
My certificate file shows a future date but browsers report it as expired. Why?+
The server is still serving the old certificate because it was never reloaded after renewal. This is the reload-hook failure, and it is the most common version of this problem. Reload the web server and verify the served certificate rather than the file on disk.
Can I see why a renewal job failed?+
The Certbot and Cron dashboards show scheduled jobs and their recent results, which distinguishes a job that ran and failed from one that never ran at all. Those have different causes and different fixes, and telling them apart is most of the diagnosis.
Try it in GateShell
GateShell is a zero-backend SSH client for iPhone, iPad, and Mac, with no vendor cloud, no accounts and no telemetry. Everything above works out of the box.
Guide reflects GateShell's shipped features as of September 2026. Steps assume basic familiarity with SSH and the command line; server-side commands may vary by distribution. All product names, logos, and brands are property of their respective owners.