June 12, 2026

Let's Encrypt 90-day renewal: the runbook that survives on-call

Let's Encrypt certificates expire in 90 days. That is not a surprise — it is the operating model. What breaks teams is treating renewal like a one-time setup task instead of a recurring production workflow with staging, monitoring, and deployment hooks.

Start with the renewal window

ACME clients may request renewal as early as 30 days before not_after. Your cron should run daily, not weekly. A weekly job that misses one weekend during a DNS provider outage leaves you with a single retry before expiry. Document the earliest safe renewal date per certificate and alert when you are inside 14 days without a successful order.

Use our ACME renewal timeline tool to map not_after to cron start dates for each hostname in your inventory.

Staging before production

Every new challenge type, DNS provider integration, or deployment target should pass through Let's Encrypt staging first. Staging rate limits are generous; production limits are not. A failed wildcard attempt against production can block your entire account for a week. Keep staging credentials in CI and run integration tests on every change to the ACME module.

Challenge method in the runbook

HTTP-01 works when port 80 reaches the validator and you control the web root. DNS-01 is mandatory for wildcards and internal services behind restrictive firewalls. The runbook must name the authoritative DNS API, the service account with least privilege, and the TTL you set during challenge propagation. If your TTL is 3600 seconds, your automation needs a propagation buffer — not a fixed 60-second sleep.

Deployment is not issuance

Issuing a new cert does nothing for users until every terminator reloads. List every target: nginx reload, Kubernetes secret patch, Azure Key Vault version, App Gateway binding, ALB listener update. Each step needs an owner, a rollback path, and a post-deploy TLS handshake check against the live hostname. Automate Certificates records each deployment in an append-only audit log so reviewers can trace which cert version reached which target.

What on-call needs on page

When renewal fails at 02:00, the engineer needs: last successful order ID, challenge type, error body from the CA, DNS propagation status, and the deployment queue. Paste these into your incident template before you need them. Pair expiry alerts with a link to the cert inventory row — not a generic "cert expiring soon" email with no hostname.

Run the certificate expiry risk calculator against your inventory quarterly. If you are in the critical tier on more than a handful of certs, your runbook is documentation — not operations.