Skip to content

← Blog

Catch Renewal Failure Alerts Before Expiry: Commands for Small Teams

By Nick Phillips, Founder

Catch Renewal Failure Alerts Before Expiry: Commands for Small Teams

Decorative SSL renewal alert title card

A renewal-failure alert means an attempted renewal did not complete. That’s different from your certificate simply getting old. Treat it like a live-process failure: verify the last renewal attempt in your logs, confirm the certificate’s actual validity window, and check that your monitoring outbox actually sent something before you assume the alert pipeline is fine.

TL;DR:

  • Renewal failure alerts often result from DNS or DNSSEC issues blocking validation, which are common and typically require checking DNS records.
  • Repeated ACME errors or consecutive 4xx/5xx responses from the CA indicate critical problems that need immediate escalation, unlike transient retries that self-correct.
  • Proper alerting setups distinguish between failure attempts and expiry countdowns, using staged reminders and webhook notifications to enable rapid automated responses.
  • Environment differences in scheduler contexts and permission errors are frequent root causes of silent renewal failures that can go unnoticed without detailed logging.
  • Small teams benefit from simple, focused alerts that quickly identify renewal issues, and monitoring services like Otterwatch help detect failures before certificates expire.
Otterwatch
Keep Certificate Failures In Sight
Otterwatch watches your SSL certificates, sends friendly expiry warnings, and quietly checks that your websites stay up.
Visit Otterwatch

Table of Contents

What Are Renewal Failure Alerts (vs. Expiry Alerts)?

Expiry is an outcome. Renewal is a process. An expiry alert tells you the countdown clock is getting short; a renewal-failure alert tells you the machinery meant to reset that clock just broke. Catching the process failure early is what actually prevents the outage, because a cert with 20 days left and three failed renewal attempts behind it is a much bigger problem than one with 20 days left and a clean renewal history.

You’ll see this show up in logs and dashboards under labels like renewal_failed, attempt_failed, or orphaned job entries where a scheduled task never reported back. Worth knowing: Let’s Encrypt and other ACME CAs now publish ACME Renewal Info (ARI) windows, a suggested time range for when a client should attempt renewal. If your client is respecting that window and a retry-after value is still in the future, a “missing” renewal attempt isn’t necessarily a failure yet. It matters for reading your alerts correctly.

What Are Renewal Failure Alerts (vs. Expiry Alerts)? — overview diagram

When Do Renewal Failure Alerts Actually Fire?

Not every hiccup deserves a page at 2 a.m. Here’s what should genuinely move you:

  • Repeated failures across multiple renewal attempts in your client logs, not a single blip.
  • ACME-specific errors like “No such authorization” or a 4xx response from the CA, both signs the challenge validation itself is broken.
  • A mismatch between your uptime/expiry checks (still green) and your renewal logs (quietly failing) — this gap is exactly where certificates expire without warning.
  • Any sign of certificate revocation, or repeated 4xx/5xx responses from the CA on consecutive attempts. Those warrant immediate escalation, not a “check tomorrow” ticket.

A single failed attempt that self-corrects on the next scheduled run is noise. Three in a row on the same domain is a signal.

What Root Causes Should You Check First?

Most renewal failures trace back to one of four places, and community reports from the Let’s Encrypt forums consistently point to infrastructure-level blockers rather than anything wrong with the certificate itself.

Four common certificate renewal failure causes

DNS and DNSSEC top the list. Run dig against the domain and check for a missing or mismatched DNSKEY record if you’re using DNS-01 validation. A broken DNSSEC chain will silently block validation while everything else looks normal.

Proxy and CDN interference comes next. If a reverse proxy or CDN is intercepting the HTTP-01 challenge path, your ACME client logs will show authorization failures even though the webserver itself is healthy.

Scheduler problems are common and easy to miss: cron running in a stripped-down environment versus systemd timers running in a full one, or an outdated client that doesn’t respect current ARI retry timing.

Hook and permission errors round it out, especially when a script referenced in a hook no longer exists or lost execute permissions after a deploy.

Run journalctl -u certbot.timer to see whether the scheduler even fired. If it did but the certificate still didn’t renew, manual runs succeeding where automated ones fail is one of the most frequently reported patterns in operator forums, almost always down to environment differences between the cron/systemd context and your interactive shell.

How Should You Design Renewal Failure Alert Cadence?

The best setup treats failed renewal attempts and expiry countdowns as two separate alarms, not one. Recurly’s own renewal-notification guidance for subscription systems makes the same case: staged reminders plus immediate failure alerts catch different failure modes, and relying on just one leaves gaps.

  1. Alert immediately on a failed renewal attempt. Don’t wait for a second failure to confirm; log it and notify.
  2. Keep staged expiry reminders running in parallel. Something like 30, 14, 7, and 3 days out as a defense-in-depth backstop.
  3. Route failure alerts through webhooks where possible, so a runbook script or CI/CD pipeline can react automatically instead of waiting on a human to read an email.
  4. Group transient retries. If the same domain fails and self-heals within one retry cycle, collapse that into a single alert rather than three separate pages.

Pro Tip: Include the last few lines of the actual renewal log in the alert payload itself. A message that says “renewal failed” tells you nothing; one that includes the ACME error string saves you a login and a grep.

Where Should Renewal Failure Alerts Route and Escalate?

Send the first failure alert to your primary on-call channel, whatever that is, Slack, PagerDuty, SMS. Send a parallel copy to the domain owner’s email and, if you have one, a webhook into your CI/CD or runbook automation.

  • Attach ownership metadata so whoever picks it up knows who’s responsible for that domain without hunting.
  • Include the last-success timestamp next to the last-attempt timestamp; the gap between them tells you how urgent this really is.
  • Attach a short log snippet, not the full file, just enough to start diagnosis.
  • Escalate to a secondary contact if there’s no acknowledgment within a reasonable window, generally an hour or two given how fast a certificate can go from “warning” to “expired.”

What If a Renewal Failure Produced No Alert at All?

Sometimes the scarier problem isn’t a failed renewal, it’s a failed renewal nobody heard about. Work through this in order:

  1. Check the monitoring outbox or intent queue directly. Is the alert worker process actually running, or did it die silently three days ago?
  2. Confirm the certificate’s monitoring record has valid contact channels attached, and that you’re not outside a configured delivery window that’s suppressing notifications.
  3. Look for orphaned jobs: a monitoring agent that went quiet, a scheduled check that got “retired” during a config change and never came back, or a queue that isn’t persisting across restarts.

A queue that silently drops messages on restart is one of the more common reasons operators say “I never got an alert” when the failure was logged the whole time.

What Should You Do in the First Two Hours?

Speed matters here, but so does not making things worse with a panicked change.

  • Check the certificate’s actual current validity first. Expired is a different emergency than “renewal failed but you’ve still got 12 days.”
  • If it’s expired or revoked, follow your emergency replacement process immediately rather than debugging the automation mid-outage.
  • Try a manual renewal with --dry-run to capture the exact error without touching the live certificate, then run a real renewal once you understand what broke.
  • If a hook is the suspected culprit, try renewing with hooks disabled to isolate the problem, and check file permissions on any hook script before you re-enable it.
  • If ACME authorization errors persist, verify the challenge path is actually reachable and that temporary validation files aren’t being blocked by a proxy or firewall rule.

Pro Tip: Keep a “renew with no hooks” command ready in your notes before you need it. Isolating hook failures from validation failures under time pressure is much harder than doing it calmly in advance.

Practitioner Tips for Fewer Silent Failures

A few habits separate teams that catch renewal problems early from teams that find out at 11:58 p.m. on the day of expiry:

  • Use deploy-hook for anything that should only run after a successful renewal; Certbot’s own documentation is explicit that pre/post hooks fire on every attempt, success or not, while deploy-hook fires only on success.
  • Skip scheduling renewals at the top of the hour. Every other server on the internet is doing the same thing, and randomized or more frequent checks avoid that thundering herd.
  • Monitor the renewal attempt itself as its own signal, separate from expiry countdown, and feed the last log lines into the alert.
  • Instrument your alert worker’s health and outbox durability directly. A monitoring system that can’t tell you it’s broken is worse than no monitoring at all.

Why Calm, Certificate-First Monitoring Actually Helps Small Teams

Single-purpose certificate alerts cut through noise faster than dashboards ever will. A small team doesn’t need graphs at 11 p.m., it needs one plain sentence telling it what broke and what to check first.

— Nick Phillips

How Otterwatch Handles Renewal Failure Alerts

This service is built around exactly the gap this article walks through: watching for renewal attempts to actually succeed, not just watching the calendar count down to expiry. It monitors a limited number of sites for free, checking certificate status and reachability together, and sends a plain-language email when something needs your attention instead of a dashboard full of red.

Otterwatch

There’s no credit card required to start, and if you just want to confirm a certificate’s current status right now, the free SSL certificate checker gives you an instant read without setting anything up. For teams that outgrow the free tier, the Pro plan runs $15 a month and adds deeper certificate monitoring and change detection. Set up your first five domains and see what a calm alert actually looks like on Otterwatch’s pricing page.

Where to Go for Deeper Troubleshooting

For log-level detail beyond this guide, the Let’s Encrypt community forum has extensive real-world failure threads, and Certbot’s official documentation covers hook behavior in full. The NIST Cybersecurity Framework is a solid reference for lifecycle and incident-response thinking beyond certificates alone.

Sources

FAQ

What Is a Renewal Failure Alert?

A renewal failure alert notifies you that an automated attempt to renew a TLS certificate did not complete, as distinct from an expiry alert that just tracks days remaining. It usually points to an infrastructure-level blocker like DNS, proxy misconfiguration, or a permissions error rather than a problem with the certificate itself.

How Is a Renewal Failure Different From an Expiry Warning?

An expiry warning is a countdown; a renewal failure is a broken process. You can have a healthy-looking expiry countdown while renewals are silently failing behind it, which is why tracking both signals separately matters more than watching expiry alone.

Why Did My Certificate Fail to Renew Automatically But Succeed When I Ran It Manually?

This is a frequently reported pattern tied to environment differences between your scheduler (cron or systemd) and your interactive shell, or to ARI retry-after timing that hadn’t opened yet when the automated attempt ran. Check journalctl for the timer and compare the environment variables available in each context.

Should I Alert on Failed Attempts or Just on Expiry?

Both, ideally. Industry practice favors immediate alerts on failed attempts paired with staged expiry reminders as a backstop, since relying on expiry alone means you find out only after the automation has already been broken for a while.

Does Otterwatch Alert on Renewal Failures or Only Expiry?

Otterwatch’s free plan tracks certificate status and reachability together across up to five sites, and it’s built specifically to flag problems before expiry becomes urgent rather than waiting until the countdown runs out. Current features and the Pro plan details are listed on Otterwatch’s pricing page.

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →