If you run one business website and you just want the padlock to keep working without you thinking about it, here is the short version: Certbot almost certainly already set up automatic renewals when you installed your certificate. Your real job is to confirm the timer is running and test that renewal actually works — which takes about five minutes and two commands.
Let's Encrypt certificates last 90 days. That short life is deliberate: it forces automation, so nobody is manually renewing anything. The failure mode isn't "I forgot to renew." It's "the renewal was set up, something quietly broke, and I found out when a customer emailed to say the site looks dangerous."
This guide is for that person — a one-site owner, comfortable in the terminal but not a sysadmin. We'll check the automation, prove it works, and be honest about when you should stop fiddling and let your host handle it.
What the renewal timer actually does
Modern Certbot installs a background timer that checks your certificates twice a day and renews any that are within 30 days of expiry. You don't trigger it; it just runs on its own.
Here's the part that trips people up. On most systems this is a systemd timer, not an old-school cron job. If you go hunting in crontab -e and find nothing, that's normal — it doesn't mean renewal is broken. The timer lives elsewhere. To see it:
systemctl list-timers | grep certbot— shows when it last ran and when it runs nextsystemctl status certbot.timer— confirms it's active and enabled
If both come back empty, your install uses cron instead. Check /etc/cron.d/certbot. You should see a line that runs certbot renew twice a day with a random delay. One of these two mechanisms exists on any sane Certbot install — you don't need both, and you shouldn't add a second one yourself.
Prove it works before you trust it
Run a dry run: sudo certbot renew --dry-run. This does everything a real renewal does — talks to Let's Encrypt, runs the validation, reloads your web server — but throws away the result, so it's completely safe to run as often as you like.
A clean dry run ends with a line like "Congratulations, all simulated renewals succeeded." That's the single most reassuring thing you can see. If it errors, the error message tells you exactly what will break in 60 days' time — while you still have 60 days to fix it, instead of finding out at expiry.
The most common dry-run failures and what they mean:
| Error points at | Usual cause | Fix |
|---|---|---|
| Port 80 / connection refused | Firewall blocks HTTP, or the validation port is closed | Allow port 80, or switch to DNS validation |
| "another instance is running" | A stuck Certbot process | sudo rm /var/log/letsencrypt/.certbot.lock then retry |
| Web server not reloading | Missing deploy hook | Add --deploy-hook "systemctl reload nginx" |
The step most people skip: reloading the web server
Renewing the certificate file is only half the job — your web server keeps serving the old certificate from memory until it's told to reload. If you've ever renewed successfully but the browser still showed the expired cert, this is why.
Certbot handles this automatically when it manages your config (the --nginx or --apache plugins add a reload hook for you). If you issued the cert in standalone or webroot mode, you need to add the reload yourself. The cleanest way is a deploy hook, which only fires when a cert actually changes:
- Nginx:
sudo certbot renew --deploy-hook "systemctl reload nginx" - Apache:
sudo certbot renew --deploy-hook "systemctl reload apache2"
Run it with the hook once and Certbot saves it into that certificate's renewal config at /etc/letsencrypt/renewal/yourdomain.conf. From then on, every automatic renewal reloads your server. Open that file and check for a renew_hook line — if it's there, you're set.
Catch failures before your customers do
The whole point of automation is that you stop watching it — so build in one alert that pokes you only when something is wrong. Two approaches, pick one.
The simplest is external monitoring. A free uptime checker that watches your HTTPS URL will email you the moment the certificate is invalid or expiring. This has a nice property: it tests the thing your visitors actually see, not just whether a command succeeded on the server. Set the check to warn you 14 days before expiry and you have a comfortable buffer.
If you'd rather keep it on the box, add a failure hook that emails you only when renewal breaks. A short cron line like this checks daily and stays silent unless something's wrong:
0 7 * * * certbot renew --quiet || echo "Certbot renewal FAILED on $(hostname)" | mail -s "SSL renewal failed" you@example.com
One alert, zero noise on good days. That's the right amount of monitoring for a single site — anything fancier is maintenance you'll resent.
When managed SSL is simply the saner choice
If you run one business website and don't enjoy the terminal, hand the certificates to your host and never think about them again. There's no prize for doing it the hard way.
Self-managed Certbot makes sense when you're on a plain VPS, you want control over the config, or you're running something unusual the host can't template. But for the person who posted on r/webhosting — one business, one site, wanting to stop babysitting SSL — a host that provisions and renews the certificate for you removes the entire failure chain described above. No timers to verify, no deploy hooks to remember, no 7am email you hope never arrives.
On shared and managed plans, TPC Hosting sets up and renews the certificate automatically, and because we're EU-hosted and GDPR-friendly, your data and your customers' data stay inside the EU. If you ever hit a snag, our AI chat is available at any hour and real engineers follow up in business hours — so you're not debugging an expiry alone at midnight. Moving an existing site over is free, and you have 30 days to back out if it isn't a fit.
Use this quick rule of thumb:
- Stay with Certbot if you're on a VPS, comfortable with systemd, and want config control.
- Go managed if SSL is a chore you want gone and one site is all you run.
Either path is fine. Just don't leave it half-done — a renewal that was "set up once" and never tested is the one that lapses.
FAQ
Do I still need a cron job if I used Certbot's snap or package install?
Usually no — those installs add a systemd timer or a cron.d entry automatically. Check with systemctl list-timers | grep certbot; if it shows up, don't add a second job, as two renewal mechanisms can conflict.
How often do Let's Encrypt certificates renew?
Certbot attempts renewal twice a day but only actually renews within 30 days of expiry. Since certificates last 90 days, this gives you a month of retries before anything can go wrong.
Why does my site still show an expired certificate after a successful renewal?
Your web server is still serving the old certificate from memory and needs a reload. Add a deploy hook such as --deploy-hook "systemctl reload nginx" so the reload happens automatically on every renewal.
Is managed SSL from my host less secure than Certbot?
No — managed SSL from a reputable host typically uses the same certificate authorities and automatic renewal under the hood. The difference is who maintains it, not the security level.
What happens if my renewal fails and I don't notice?
Visitors get a browser security warning and many will leave immediately. Set up one alert — either an external uptime monitor watching your HTTPS URL or an email failure hook — so you hear about it weeks before expiry.
