← Blog

How to Combine SSL and Uptime Alerts in One Calm Setup

October 21, 2026

By Nick Phillips, Founder

How to Combine SSL and Uptime Alerts in One Calm Setup

You can combine SSL and uptime alerts by running both checks against the same list of hostnames and sending them to one inbox, with different urgency for each. Certificate expiry is a slow problem: you want weeks of notice. Downtime is a fast one: you want to know within minutes. Treat them as two signals on one site, not two separate tools with two sets of noise.

This guide walks through how to set that up, which thresholds to use, and why the two checks catch different failures that often show up as the same symptom: a visitor staring at a browser warning or a dead page.

TL;DR

• Put SSL expiry and uptime checks on the same hostnames and the same alert channel, so one problem produces one message.
• Use early, quiet expiry warnings (30 days, then 14, then 7) and fast, short-fuse uptime alerts. Different clocks, same inbox.
• Monitoring is a safety net for automated renewal, not a replacement for it. Alert when the automation breaks.
• Check the whole hostname list, including API endpoints, subdomains and old microsites, because those are what get forgotten.
• You can start free: Otterwatch watches five sites at no cost, certificates first and uptime alongside.

Table of Contents

• Why SSL and uptime belong in the same setup
• Automation first, alerts as the safety net
• Step by step: one list, two clocks
• Watch out for these common traps
• DIY or a tool?
• Our perspective: certificates first, uptime as the calm bonus
• Try it on your own sites
• FAQ
• Sources

Why SSL and uptime belong in the same setup

An expired certificate and a downed server look nearly identical to a visitor. The page does not load, or it loads behind a full-screen warning. To you, they are very different problems with very different fixes, but the place you find out should be the same.

There is a second reason. Browsers treat an expired certificate as a hard stop, so from your customer’s side an expiry is downtime. A plain uptime check that only asks “did the server answer?” can still say yes while real visitors are blocked, depending on how the check treats certificate errors. A certificate-aware check closes that gap.

The two checks also fail on different schedules:

So “combining” does not mean one threshold for everything. It means one list of sites, one place for alerts, and two sensible clocks.

Automation first, alerts as the safety net

Before wiring anything up, be clear about the job alerts do. They are not your renewal process.

Certificate lifetimes are getting shorter. Let’s Encrypt currently issues 90-day certificates and plans to cut that to 64 days in February 2027 and 45 days in February 2028. At those lifetimes, hand-renewing is a recurring chore with a real chance of being forgotten. Automation is the only approach that holds up.

The UK’s National Cyber Security Centre makes a point we agree with: you should monitor your certificate renewal so certificates do not expire unexpectedly because of misconfiguration, hardware failure or software failure. In other words, the monitor is there to tell you that the automation broke. It is the second pair of eyes.

And you can no longer count on your certificate authority to be that second pair. Let’s Encrypt ended its expiration notification emails on June 4, 2025, citing the maturity of renewal automation and the cost and privacy burden of holding millions of email addresses. If you relied on those emails, you now need your own watcher.

If you are chasing a renewal that quietly failed, our write-up on why a Let’s Encrypt auto-renewal silently failed covers the usual culprits, and the one on Certbot dry runs shows how to test renewal before it matters.

Step by step: one list, two clocks

Here is the setup we recommend for a solo founder, a freelancer or a small team without a dedicated ops person.

1. Inventory every hostname that serves HTTPS

Start with the obvious ones: your main domain and www. Then add the ones people forget:

• API endpoints (api.example.com)
• App and staging subdomains that real users or partners touch
• Marketing microsites and old campaign pages
• Client sites, if you manage them
• Anything behind a separate CDN or load balancer, which may carry its own certificate

Check a few of them quickly with our free SSL certificate checker to see the issuer, the expiry date and whether the certificate actually covers the name you expect (the SAN list trips people up more often than the date does).

2. Set expiry warnings that start early

The renewal guidance is a useful anchor. Let’s Encrypt recommends renewing once a third of the lifetime remains, which is about 30 days before expiry for a 90-day certificate. That means your automation should normally renew around day 60.

So your alerts should fire after the point where renewal should already have happened. A sensible ladder for 90-day certificates:

If you see a 30-day warning on a certificate you thought was automated, that is the monitor doing exactly its job. For a deeper look at tiers and timing, see our guide to SSL certificate expiry alert types.

Shorter lifetimes change the math. As certificates drop to 64 and then 45 days, a fixed “30 days” warning becomes proportionally much louder. Scale your thresholds to the lifetime rather than copying numbers forever. Using the one-third rule, a 45-day certificate should renew with about 15 days left, so your first warning belongs at roughly 14 days, not 30.

3. Set uptime checks that are patient, not twitchy

Uptime alerts have the opposite problem: too sensitive and you get paged for a blip. A few habits keep them calm:

• Check over HTTPS, so the check exercises the TLS handshake the way a visitor’s browser does.
• Require two failures in a row before alerting. One dropped request is usually the network, not your site.
• Alert once on failure and once on recovery. Not every minute in between.
• Check the endpoints that matter, such as the login page or the API health route, not only the homepage.

External checks run from outside your own network are the only kind that see what your visitors see. Large cloud providers document the same idea: public uptime checks send periodic HTTP, HTTPS or TCP requests from multiple locations around the world. You do not need a global fleet for a side project, but you do need a check that is not running on the server it is judging.

4. Send both to one channel

Pick a single destination. For most small teams that is an email address that someone actually reads, or a shared alias that forwards to the whole team. Slack and webhook delivery are useful once you have an on-call habit, but an inbox people open is better than a channel everyone has muted.

A few rules for routing:

1. One message per problem. If a certificate expired and the site is down, you want to know both, but ideally in a way that makes the connection obvious.
2. Different subject lines for “certificate expires in 14 days” and “site not responding”, so you can triage from the notification.
3. Agencies: split by client. Send each client’s alerts to a client-specific address or alias, so one customer’s expiring certificate does not bury another’s.
4. Do not put alerts only in one person’s inbox. Vacations happen.

5. Make sure the alert itself gets delivered

This is the part people skip. Alert emails that land in spam are worse than no alerts, because you think you are covered. Allow-list the sender, send a test, and if email is your only channel, think about what happens when your own mail provider is the thing that is down. Guides on SMTP failover and backup relays explain how teams keep notification mail flowing when a primary route fails, which is worth reading if your alerts go out through your own infrastructure.

6. Test it, then review it quarterly

Use a certificate you control with a short remaining lifetime, or simply send a test alert, and confirm someone sees it. Then put a quarterly reminder on your calendar to compare your hostname list against reality. New subdomains appear constantly, and an unmonitored one is where the next surprise lives.

Watch out for these common traps

• Monitoring only the apex domain. Subdomains often have separate certificates and separate renewal jobs.
• Checking the date but not the certificate. A renewed certificate that was issued for the wrong names, or a renewal that never reached the server, still produces errors. Change detection, meaning an alert when the served certificate differs from last time, catches unexpected swaps.
• Renewed on disk, not loaded in memory. The file is fresh but the web server never reloaded. An external check sees the old certificate and tells you.
• Alert fatigue. Dozens of 30-day warnings for the same fleet teach you to ignore the 3-day one. Fewer, clearer alerts win.
• Retry storms. If a renewal fails, hammering the authority makes it worse. Let’s Encrypt recommends backing off between retries (their example grows from a minute to ten minutes to hundreds of minutes) instead of retrying constantly.

If you want to see how the different tool types stack up before choosing, we have an honest comparison of SSL monitoring tools, and a walk-through of setting up expiry notifications if you prefer to build your own.

DIY or a tool?

You can absolutely roll your own: a cron job that reads the expiry date and sends mail, plus a separate uptime ping. We even wrote up a certificate expiration check script for exactly that. It works well for one or two domains.

It gets fragile as the list grows. Scripts fail silently, they run on one server, they do not remember what the previous certificate looked like, and nobody monitors the monitor. If you want the reports your clients or teammates can read, you also end up building a formatting and delivery step. Teams that automate scheduled report delivery by email, as with report delivery automation for business intelligence tools, know the same lesson: the sending part needs error handling too.

Our perspective: certificates first, uptime as the calm bonus

We built Otterwatch because most monitoring tools assume a big ops team. They give you dashboards, graphs and a wall of red, and a solo founder or a freelancer with twelve client sites needs none of that. They need to know, early and plainly, that a certificate is about to expire.

So we put certificates first. Expiry is the failure that is entirely predictable and still takes sites down every week, usually because a renewal job broke months ago and nobody noticed. Uptime checks run alongside, quietly, because the same hostnames are already on the list and a site that is down deserves a heads-up too. But we deliberately keep it low-noise: a plain email from Otis, our park ranger otter, rather than alarm language.

Our view is that combining the two is mostly a discipline of restraint. One list, one inbox, early warnings for slow problems and quick ones for fast problems. If you find yourself building a dashboard to understand your alerts, there are too many alerts.

— Nick Phillips

Try it on your own sites

Otterwatch is free for up to five sites, with no credit card required. You get certificate expiry alerts and uptime checks by email, and you can paste any hostname into the free certificate checker first to see what it says. When you outgrow five sites or want deeper certificate monitoring and change detection, the Pro plan is $15 per month; the details are on the pricing page. Agencies juggling many small client sites may also like our notes on monitoring microsite certificates without the noise.

FAQ

Should SSL expiry alerts and uptime alerts use the same thresholds?

No. Expiry is slow, so it needs warnings measured in weeks, starting around when your renewal should already have run. Uptime is fast, so it needs a check every few minutes and an alert after a couple of consecutive failures. Same inbox, different clocks.

How many days before expiry should I get an SSL alert?

For 90-day certificates, 30, 14 and 7 days is a solid ladder, since renewal is recommended at about 30 days left. As lifetimes shrink toward 45 days, move the first warning closer, around 14 days. Any warning you receive while automation is working is a sign something needs a look.

Does an uptime check catch an expired certificate?

Only if the check validates the certificate over HTTPS. Some checks treat certificate errors as success as long as the server answers, so do not assume. A dedicated expiry check is the reliable way to know weeks ahead rather than at the moment visitors hit a warning.

If I automate renewals, do I still need monitoring?

Yes. Automation can break from misconfiguration, a server change or a failed hook, and the NCSC advises monitoring renewal for exactly that reason. Since Let’s Encrypt stopped sending expiry emails in 2025, you have to be your own backstop.

Sources

• Certificate Lifetime Rationale and Plans, Let’s Encrypt
• Integration Guide, Let’s Encrypt
• Expiration Notification Service Has Ended, Let’s Encrypt
• Provisioning and managing certificates in the Web PKI, UK NCSC
• Create public uptime checks, Google Cloud Documentation

Recommended

• Downtime Alerts: Two Regions, SSL Checks, Less Noise for Small Teams
• 60/30/14/7 Slack SSL Alerts for Small Teams
• Three Probes for Small Teams’ SSL First Multi Region Uptime Checks