How to Automate SSL Certificate Renewal Alerts Before Expiry: A Step-by-Step Guide for Sysadmins

The most reliable way to automate SSL renewal alerts is to use an SSL certificate monitor that checks each hostname's live certificate on a schedule and warns you at several stages before expiry. My default is 30, 14, 7 and 1 days out. Send those alerts to the channels your team already watches, like email, Slack or webhooks, then test the whole pipeline so you know it works before you need it.

That's the short version. The rest of this guide walks through how to set up automated SSL monitoring step by step, whether you're looking after five sites or five hundred. Grab a tea. 🍵

One bit of transparency before we start: I'm on the Moonitor team, so the hands-on examples use Moonitor. I've kept the principles and a tool-neutral checklist separate, so you can apply everything here to whichever monitoring tool you use.

Why manual SSL certificate tracking fails (and why I've seen it bite good teams)

Picture this. It's a quiet Tuesday morning and someone pings the helpdesk: the customer portal is showing a big red browser warning. You open the renewal spreadsheet. It was last updated eighteen months ago. The colleague who set up the calendar reminder left in the spring, and the reminder went with their account. Nobody was careless. The process just quietly rotted.

I've seen this happen to really good teams, and I want to say that up front, because it's easy to feel embarrassed about it. It's very fixable.

Spreadsheets and calendars drift

Certificates, domains and ownership change constantly. A spreadsheet is a snapshot of what someone believed on the day they typed it in. Calendar reminders depend on one person's account, one person's inbox and one person's memory. The moment a certificate is reissued, moved to a new load balancer or handed to a different team, the record starts drifting from reality.

Shadow certificates

Then there are the certificates nobody remembers. Staging sites that quietly became semi-production. Forgotten subdomains. Client domains you look after but don't fully control. Third-party endpoints your integrations depend on. If it isn't in your inventory, it isn't in your reminders, and it will expire on its own schedule.

Auto-renewal isn't guaranteed renewal

You might be thinking, 'But we use Let's Encrypt, so it's automatic.' Lovely, and you should. Let's Encrypt certificates last 90 days, and the project explains why it encourages automated renewal. It has also ended its expiry reminder emails, so you can't lean on those as a backstop any more. And automated is not the same as guaranteed. Renewals fail because of:

• a cron job or systemd timer that stopped running after a server migration
• DNS validation changes that break the challenge
• rate limits
• expired API tokens for your DNS provider
• a renewed certificate that never got reloaded into the web server, or reached only one of several load balancers

That last one is the classic. The renewal job reports success, the new certificate sits happily on disk, and one node behind the load balancer carries on serving the old one until it expires. Dashboards say green. Some users see errors.

Managed services have conditions too. AWS Certificate Manager can renew eligible certificates automatically, but its managed renewal documentation lists requirements, such as the certificate being in use and its domain validation remaining possible. Change something underneath it and a renewal can fail without much fanfare.

And the clock is speeding up. The CA/Browser Forum has adopted a schedule (ballot SC-081v3) that cuts the maximum validity of publicly trusted TLS certificates from 398 days to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. More renewals means more chances for something to slip, and a spreadsheet simply won't keep up.

What an SSL certificate expiry actually costs

When a certificate lapses, the damage depends on what the hostname does. On a public website, visitors get browser warnings and many will turn back. On an API or webhook endpoint, clients usually refuse the connection outright, so integrations fail until someone fixes it. Internal tools, mail gateways and VPN portals each fail in their own way, depending on how strictly the client checks certificates. Then comes the out-of-hours firefighting.

Even giants get caught. Microsoft Teams suffered widely reported outages linked to expired certificates in 2020 and 2021. If it can happen there, it can happen to us.

What a good automated SSL monitoring setup looks like

Before we click anything, let's agree on what 'good' means. Here's the checklist I measure setups against, and it works with any tool:

• It checks the live certificate. The monitor looks at what the endpoint is actually serving, not a record of what you think you installed. That catches failed deployments and missed reloads.
• It alerts at several stages. One last-minute warning is a panic button. A few stages give you time to plan, act and escalate.
• It covers every serving endpoint. Separate load balancers, CDNs, regions and mail or API gateways may each present their own certificate, so check each one that matters.
• It connects with the right hostname. Many servers use SNI to choose which certificate to present. A check that connects by IP address, or with the wrong server name, can see a default certificate rather than the one your users get.
• It tells failure types apart. An expiring certificate, a hostname mismatch and a broken intermediate chain are different problems with different fixes, so your alerts should say which one you have.
• It pairs SSL expiry with domain expiry. They protect against different failures, and a lapsed registration undoes all your good work.
• It reaches people who actually read it. Use channels your team genuinely watches, and name an owner.
• It keeps noise low. If alerts get ignored, they might as well not exist.

That's the whole idea behind automated SSL monitoring: an outside-in check that doesn't rely on anyone's memory. It doesn't replace renewal-job logs and deployment checks. Think of it as the independent second opinion on whether those worked.

Step-by-step: set up multi-stage SSL expiry alerts

The steps below use Moonitor's SSL and domain expiration monitor type, but steps 1, 3, 5 and 6 apply to any tool. At the time of writing Moonitor offers a 7-day free trial with no credit card, so you can follow along with your own domains. Do check the current terms on the Moonitor site.

Step 1: Build an inventory of hostnames and endpoints

List every hostname that serves HTTPS. Don't stop at the marketing site. Include:

• APIs and webhook receivers
• mail gateways and webmail
• admin panels and VPN portals
• staging and testing hosts that real people use
• client sites you're responsible for

Pull from DNS zone files, load balancer configs, your cloud console and your certificate authority's issued-certificate list. Certificate transparency logs are also handy for spotting hostnames you'd forgotten. Ten minutes of digging usually turns up at least one surprise.

For each hostname, note every distinct endpoint that serves it: separate load balancers, regions, CDN edges and any direct-to-origin addresses people actually use. That's how you confirm coverage later.

Step 2: Create an SSL certificate monitor for each hostname

In Moonitor, add a new monitor and choose the SSL and domain expiration type. Enter the hostname, give it a clear name, and save. The check connects to the live endpoint, so you're watching what clients actually see.

Two things are worth confirming here. First, the monitor should connect using the real hostname so that SNI selects the right certificate. Second, if the same hostname is served by several independent endpoints, one hostname-level monitor may only ever see one of them. In that case, add a monitor for each endpoint where your tool supports it, or at least cover the ones deployed separately. One monitor per hostname is fine when a single endpoint serves it. It stops being enough when each endpoint needs its own certificate deployment.

Step 3: Choose your SSL expiry warning thresholds

My standard schedule is 30, 14, 7 and 1 days. Tailor it to your renewal process. If renewal is a quick automated job, you can be leaner. If it needs a purchase order and a sign-off, start earlier. Some teams add an extra late-stage warning at 3 days, which gives 30, 14, 7, 3 and 1. That's a variation on the same idea. We'll compare the options in the next section.

Step 4: Add a domain expiration monitor alongside each SSL monitor

Certificates get the glory, but registrations expire too, and the two checks catch different failures. An SSL check tells you what certificate is being served. A domain check tells you whether you'll still own the name. Track the domain with matching alert stages so you hear about both in the same place. You only need one domain monitor per registered domain, not one per subdomain. This step is easy to skip and painful to regret.

Step 5: Assign alert channels to each stage

Early warnings can go to a shared team channel, where they're visible and low-pressure. Late-stage warnings should escalate to whoever is on call. Moonitor supports email, Slack, Discord, Telegram and webhooks, so you can mix them to suit your team.

Step 6: Add context to every SSL expiry alert

A name like acme-prod-api.acme.co.uk tells you far more at 7am than Monitor 14. Use a consistent pattern, and note who owns the renewal and where the certificate was issued (Let's Encrypt, a commercial CA, a cloud provider). That makes the alert actionable the moment it lands.

How many SSL expiry warning stages should you set?

There's no universal standard here. What follows is operational advice, not an industry rule, but it's grounded in how renewals actually behave.

The logic is simple: early warnings are for planning, mid-stage warnings are for action, and late-stage warnings are for urgency.

Schedule	Stages (days before expiry)	Best for	Watch out for
Simple	14 / 3	90-day automated certificates with solid renewal automation	Little slack if something breaks over a weekend
Standard (my default)	30 / 14 / 7 / 1	Most teams, including 1-year commercial certificates	Add a 3-day stage if you want a second late warning, or a 60-day stage if approvals are slow
Extended	60 / 30 / 14 / 7 / 3 / 1	Certificates needing procurement, approval or client sign-off	Can feel noisy if you don't route stages sensibly

Match your SSL alert schedule to the certificate

• For 90-day automated certificates (Let's Encrypt), the Certbot documentation recommends running renewal twice a day, and by default Certbot renews certificates that are within 30 days of expiry. That makes a warning at 14 days a strong signal that automation has failed. If you're still looking at the old certificate at 14 days, something is wrong. If your client uses different renewal timing, adjust accordingly.
• For 1-year commercial certificates, the standard 30/14/7/1 pattern works well. You have time to generate a CSR, validate and deploy.
• For approval-required or client-managed certificates, add a 60-day stage. Organisation-validated and extended validation certificates can take longer to issue, and clients rarely reply on the first email.

Don't overdo SSL expiry alerts

More stages isn't always better. Six emails for one certificate teaches people to filter them out. Pick a schedule, give each stage a different response (a ticket, a ping to the owner, a page), and stop there.

Adjust alert thresholds as certificate lifetimes shrink

With the CA/Browser Forum's reductions on the way, fixed warnings at 30, 14 and 7 days may land close together, or too late, for shorter-lived certificates. A 47-day certificate with a 30-day warning is practically always in alert territory. Base your thresholds on the certificate's actual validity period, and test your renewal workflow before you tighten anything.

My recommended default stays the same: 30, 14, 7 and 1 days, with a 60-day stage added for anything that needs a human to approve it, and an optional 3-day stage if you want one more late warning.

Monitoring SSL certificates across multiple domains without losing your mind

Yes, you can monitor SSL for dozens, even hundreds, of domains at once. The trick is keeping it manageable, and most of that comes down to habits rather than tools.

Name things consistently. Use a pattern such as client-environment-hostname. When an alert fires, you should know whose problem it is from the title alone.

Create monitors in bulk. Start from your inventory rather than adding hosts as you remember them. If your tool has an API (Moonitor does), script monitor creation and plug it into whatever provisions your domains. New site goes live, monitor appears automatically. No gaps.

Handle wildcard and shared certificates sensibly. Say one wildcard certificate covers a dozen hostnames that all sit behind the same load balancer. You don't want a dozen alerts for one renewal, so monitor the primary hostname and a couple of representative ones. But suppose api.example.co.uk is served from a separate gateway and mail.example.co.uk from a mail server. Each of those needs the new certificate deployed separately, so each deserves its own check, even though they share one certificate. The rule of thumb: monitor once per distinct serving endpoint, not once per name.

Pick a plan that fits. At the time of writing, Moonitor's Solo plan is $14/mo for 20 monitors, which is plenty for a small estate (remember that each SSL and domain pair counts separately). The Max plan is $49/mo with unlimited monitors, which suits agencies and larger environments. Prices change, so check the pricing page before you decide.

Get the data out. Where your tool offers an API or data export, feed certificate expiry information into your own reporting or CMDB, so your asset records stay honest.

Watch the neighbours. DNS changes often precede certificate validation failures. A DNS monitoring check that flags record changes can warn you before a DNS-validated renewal quietly breaks. If you manage a lot of sites, pairing SSL certificate monitoring with website monitoring and uptime monitoring gives you a fuller picture from a single dashboard.

Integrating SSL renewal alerts with your team's workflow

An alert only helps if the right person sees it at the right time. Here's how I'd wire things up.

• Email gives you the paper trail. Point it at a shared mailbox such as it-alerts@ so alerts survive staff changes.
• Slack, Discord or Telegram suit visible, collaborative early warnings. Someone sees it, someone says 'I've got this', done.
• Webhooks can create tickets in Jira, ServiceNow or your helpdesk, or trigger a renewal script directly.
• Escalation is the glue. Early stages create a ticket, and late stages page a person.

Give every SSL renewal an owner

An alert that's everyone's problem is no one's problem. Put a named owner (or a named team) in the monitor's name or notes. When the 14-day warning appears, there should be no debate about whose it is.

Let stakeholders see you're on top of SSL monitoring

If clients or colleagues keep asking 'is everything okay?', a branded public status page and incident history can answer that without you writing a single email. It's a small thing that builds a lot of trust.

Account for UK bank holidays and local time

If your certificate expires on 2 January, a 7-day warning lands in the middle of the Christmas shutdown. Bank holidays, Easter weekends and summer leave all eat into your lead time, and they differ across the UK. 2 January is a bank holiday in Scotland, St Andrew's Day matters for Scottish teams, and 12 July is observed in Northern Ireland. If your estate or clients span nations, check the right calendar. Where a renewal falls near a shutdown, move the first warning earlier so the work happens while everyone's still at their desks.

Two more small habits help. Check whether your alert timestamps are in UTC or local time, because 'expires at midnight' can mean a different evening during British Summer Time. And for .uk and .co.uk domains, find out who actually handles renewal, whether that's you, your registrar or a client. Registrations often sit with an agency or a former supplier, and that's exactly where expiry surprises come from.

Testing your SSL renewal alert pipeline

I'll be blunt: an alert setup you've never tested is a hope, not a control. Here's a short routine that takes under an hour.

1. Send a test notification to every connected channel. Confirm it lands where you expect, not in spam or a muted channel.
2. Trigger a real alert. Point a monitor at a short-lived test certificate or a staging host, and set a high threshold so an alert fires straight away.
3. Read the alert like a stranger would. Is the hostname clear? Is the expiry date visible? Does it say who owns the renewal?
4. Check your webhooks. Confirm the payload reaches your ticketing system and creates the right record, with the right priority.
5. Verify coverage per endpoint. For each hostname with several load balancers or regions, confirm each endpoint is checked and presents the certificate you expect, using the correct server name.
6. Run a fire drill with on-call. Ask the person who'd get paged what they'd do. If the answer is 'um', you've found a gap worth fixing now.
7. Schedule a quarterly review. Prune old monitors, add new domains and re-check thresholds, especially as certificate lifetimes shorten.
8. Watch the automation, too. Add heartbeat monitoring (cron job monitoring) to your renewal jobs, alongside your SSL and uptime checks. Then you hear about the renewal script failing weeks before the certificate gets anywhere near expiry.

That last one is my favourite trick. A heartbeat that goes quiet is an early warning of a very different kind.

What happens if you miss an SSL renewal alert?

First, breathe. It's a process problem, not a personal failure, and you're far from the first.

The immediate impact of an expired SSL certificate

On public sites, browsers display security warnings and many visitors will simply leave. API calls and webhook deliveries to the affected hostname typically fail, because most clients refuse expired certificates. Mail is more variable: some servers deliver regardless of an expired certificate, while others enforce TLS and will defer or bounce messages. Longer term, the real risks are lost customer trust and awkward conversations with clients or compliance teams. Any search ranking effect depends on how long the problem lasts and which pages are affected, so I wouldn't promise one either way.

A calm SSL certificate recovery checklist

1. Confirm the expiry. Check the certificate being served, not just your renewal dashboard.
2. Work out what failed. Is it expiry, a hostname mismatch or a broken intermediate chain? The fix differs for each.
3. Issue or renew the certificate.
4. Deploy it everywhere: web servers, load balancers, CDNs, reverse proxies and any other endpoint using that hostname. A certificate can be renewed successfully and still cause an outage if one server never picks it up.
5. Reload services and clear caches where needed.
6. Verify externally. Check the live endpoint from outside your network.

This is where multi-region verification earns its keep. If one load balancer is still serving the old certificate, a check from a single location might look fine while some users still see errors. Confirming from multiple regions means a partial rollout can't fool you.

Learn from the missed alert

Hold a short, blame-free review. Which stage fired, and who saw it? Was the owner clear? Did the channel work? Adjust your thresholds, owners and channels, then move on a bit wiser.

Frequently asked questions about SSL renewal alerts

How do I automate SSL expiration alerts?

Create an SSL monitor for each hostname in a monitoring tool, set several warning thresholds (for example 30, 14, 7 and 1 days before expiry), and send the alerts to channels your team already uses, such as email, Slack or webhooks. The tool checks the live certificate automatically, so you don't need to maintain a spreadsheet or calendar.

How many warning stages should I set before expiry?

For most teams, four stages at 30, 14, 7 and 1 days is a solid starting point. If your renewal needs approvals or procurement, add an earlier 60-day warning. If you want a second late-stage nudge, add a 3-day stage. If you rely on auto-renewing 90-day certificates, a 14-day alert is a useful safety net that tells you automation has failed.

Can I monitor SSL for dozens of domains at once?

Yes. Build an inventory, create a monitor for each distinct serving endpoint, and use consistent naming so alerts are easy to triage. Bulk creation through an API and plans with higher monitor limits make larger estates easier to manage, though the details vary by tool.

What happens if I miss an SSL renewal alert?

Visitors to affected public sites will see browser security warnings, and API clients may refuse to connect. The exact impact depends on the service. Renew and deploy the certificate as quickly as possible, verify it externally, then review your alert stages and ownership so it doesn't happen again.

Is auto-renewal enough, or do I still need SSL renewal alerts?

I'd still set up alerts. Auto-renewal can fail silently because of expired credentials, changed DNS records, rate limits, a broken cron job or a missed reload. Monitoring the live certificate is an independent check that the renewal reached production. Use it alongside renewal-job logs, heartbeat monitoring and deployment verification.

Should I monitor domain expiry as well as SSL certificates?

Yes. A lapsed domain registration will take your site offline no matter how healthy your certificate is, so it makes sense to track both with matching alert stages in the same place.

Wrapping up

Nobody enjoys finding out about an expired certificate from an angry customer. The fix isn't heroics. It's a small amount of setup done once: inventory your hostnames and endpoints, monitor the live certificates, warn at several stages, send alerts to real owners, and test the lot.

If you'd like to try it with Moonitor, there's a 7-day free trial (check the site for current terms). Start with your five most important domains, and build out from there. 💙