What do you check, in order, when a Let's Encrypt renewal fails silently 20 days before expiry?

What do you check, in order, when a Let's Encrypt renewal fails silently 20 days before expiry?

Let's Encrypt issues 90-day certificates via the ACME protocol (Automatic Certificate Management Environment, RFC 8555); the recommended renewal window opens at 30 days. A stalled renewal that no one watched is the classic outage. Triage runbook.

— Read the client log first: journalctl -u certbot.timer and /var/log/letsencrypt/. The failing challenge type is named there.
— For HTTP-01: confirm port 80 still reaches the challenge path; a later firewall change or an HTTPS-only redirect that 301s the /.well-known/acme-challenge/ path is the usual culprit.
— For DNS-01: confirm the API credentials for your provider have not rotated and the TXT record actually propagates.
— Check rate limits: 5 failed validations per account per hostname per hour will lock you out temporarily; back off rather than loop.
— Dry-run before trusting the fix: certbot renew --dry-run hits the staging endpoint and proves the full flow without burning quota.

Evidence vs. speculation: the log states the cause; do not guess. Most 'mystery' failures are a redirect swallowing the HTTP-01 path.

Further reading: RFC 8555 sections 7 and 8; Let's Encrypt rate-limit docs.

Bottom line: monitor the renewal job's exit code, not the certificate's expiry date.