Let's Encrypt pauses issuance for an identifier when one account racks up too many consecutive failed validations. The error includes a link to its Self-Service Portal where you can unpause. Unpausing does not fix the cause, so find out why validation fails first, or the pause returns.
How the pause works
Let's Encrypt has two failure limits. The first allows 5 authorization failures per identifier per account every hour, refilling 1 every 12 minutes. The second, the consecutive failure limit, targets clients stuck in a loop: up to 1,152 consecutive failures per identifier per account, with 1 refilling per day. A successful validation resets the count to zero.
Once exceeded, the account cannot request new certificates for that identifier. Each attempt returns an error with a link to the Self-Service Portal, where you can unpause that identifier and up to 49,999 additional paused identifiers on the account.
How fast a loop gets you paused
The documentation gives a table of failures per day against the time until a pause:
| Failures per day | Time to pause |
|---|---|
| 1 | Never paused |
| 2 | 1,152 days |
| 5 | 288 days |
| 10 | 128 days |
| 20 | 61 days |
| 40 | 30 days |
| 120 | 10 days |
So a single failing renewal retried once a day never trips it. A runaway script retrying every few minutes will.
Find the cause before you unpause
The documentation says to switch to the staging environment while troubleshooting, because its limits are far higher, and describes the usual causes by challenge type.
- HTTP-01 and TLS-ALPN-01: network or firewall settings stop the validation servers from reaching you. Check port 80 or 443 from outside, redirects, and load balancer rules.
- DNS-01: usually a missed step or typo in the first setup, often a CNAME in the main zone so the client can write the TXT record.
See challenge type tradeoffs and delegating the DNS challenge.
Steps to recover
- Stop automatic retries so you do not add failures.
- Reproduce on staging and fix the network, DNS or config problem.
- Confirm the challenge path answers correctly from outside your network.
- Open the Self-Service Portal link from the error and unpause the identifier.
- Run one manual issuance and confirm success, which resets the consecutive counter.
- Add alerting on renewal failures so you see a first failure, not the thousandth.
Prevent it
Back off retries in your own scripts. Many ACME clients already do this, but a wrapper that restarts a crashing container every minute can defeat it. Decommissioned hostnames are another source: a renewal job still requests a name whose DNS was removed. Delete the job along with the record.
Where Safeguard fits
Safeguard does not run ACME. It gives teams SBOM and dependency scanning plus policy gates over the code that configures TLS. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does a successful issuance clear the count?
Yes. The consecutive count resets to zero when an authorization for that identifier validates.
Can I ask for an override of this limit?
The rate limits page states that no overrides are offered for the authorization failure limits.
Is the pause permanent?
No. You can unpause through the Self-Service Portal, and capacity also refills at 1 per day.
Sources
Last reviewed: 19 October 2026.
