# Let's Encrypt rate limit errors: find the limit and recover

> Let's Encrypt "too many certificates" or rateLimited means you hit an issuance limit. Identify the limit, wait for the refill and prevent a repeat.

Source: https://ssl.sh/errors/lets-encrypt-rate-limit/
Last updated: 2026-11-10

**A `rateLimited` error means Let's Encrypt refused a new account, order or certificate because you used up one of its issuance limits.** The most common trigger is reissuing the same certificate again and again while debugging, which hits the "5 certificates per exact set of identifiers per 7 days" limit.

## Quick fix

Read the error text: it names the limit and gives a `retry after` time in UTC. Then:

1. **Stop retrying.** Every failed attempt may consume more capacity. Disable cron jobs, CI pipelines or container restarts that call your ACME client in a loop.
2. **Reuse what you have.** Certbot keeps every issued certificate under `/etc/letsencrypt/archive/<name>/`; acme.sh keeps them under `~/.acme.sh/<name>/`. Install the newest valid one.
3. **Debug against staging.** Point your client at staging until issuance works, then switch back:

```bash
certbot certonly --staging -d example.com -d www.example.com
acme.sh --issue --staging -d example.com -w /var/www/html
```

## Causes

Duplicate certificates cause most rate limit errors; the other three limits are hit less often. The numbers below are taken from the Let's Encrypt rate limits page (last updated 5 August 2026). Limits change from time to time, so treat the official page as authoritative.

| Limit | Allowance | Refill | Override |
|---|---|---|---|
| New certificates per exact set of identifiers | 5 per 7 days | 1 every 34 hours | Not offered |
| New certificates per registered domain | 50 per 7 days | 1 every 202 minutes | On request |
| New orders per account | 300 per 3 hours | 1 every 36 seconds | On request |
| Authorization failures per identifier per account | 5 per hour | 1 every 12 minutes | Not offered |
| Consecutive authorization failures per identifier per account | 1,152 | 1 per day; resets on success | Unpause via self-service portal |
| New registrations per IP address | 10 per 3 hours | 1 every 18 minutes | Not offered |
| New registrations per IPv6 /48 | 500 per 3 hours | 1 every 22 seconds | Not offered |

### 1. Duplicate certificates (most common)

- **Confirm:** the message says "exact set" of identifiers or domains. Search [CT logs](https://ssl.sh/tools/ct-search/) for the name; you will see several certificates with identical names issued in the last week.
- **Typical causes:** deleting the client's config directory on every deploy, rebuilding containers without a persistent volume for `/etc/letsencrypt`, or running `--force-renewal` while testing.
- **Fix:** wait for the refill, reuse an existing certificate, and persist the client's state directory.

### 2. Too many certificates for one registered domain

- **Confirm:** the message mentions the registered domain (for example `example.com`) rather than the exact list of names. This happens when you issue separate certificates for many subdomains.
- **Fix:** combine names into fewer certificates (one certificate can hold up to 100 identifiers on the classic profile), use a [wildcard certificate](https://ssl.sh/glossary/wildcard-certificate/) through DNS-01, or request an override if you are a hosting provider.

### 3. Repeated validation failures

- **Confirm:** the error mentions failed authorizations. The real problem is validation: see [certbot timeout during connect](https://ssl.sh/errors/certbot-timeout-during-connect/), [certbot 403 unauthorized](https://ssl.sh/errors/certbot-unauthorized-403/) or [NXDOMAIN](https://ssl.sh/errors/certbot-dns-problem-nxdomain/).
- **Fix:** fix validation on staging first. If issuance for a name is paused after long-running failures, the error contains a link to the self-service portal where you can unpause it.

### 4. Too many accounts from one IP

- **Confirm:** "too many new registrations". Usually caused by scripts that register a fresh ACME account for each certificate.
- **Fix:** register one account and reuse it for all certificates.

## Fixes by environment

Every client avoids the limits the same way: keep its state on persistent storage, debug against staging, and never force renewal on a schedule.

**Certbot:** `certbot certificates` lists what you already have; `certbot renew` only renews certificates within the renewal window, so avoid `--force-renewal` in cron. Persist `/etc/letsencrypt` in Docker.

**acme.sh:** keep `~/.acme.sh` on a persistent volume; use `--staging` (or `--test`) while debugging and remove `--force` from scheduled jobs.

**Kubernetes cert-manager:** a Certificate stuck in a failure loop can burn through limits. Use a staging ClusterIssuer until the Certificate becomes Ready; see [cert-manager certificate not ready](https://ssl.sh/errors/cert-manager-certificate-not-ready/).

**Hosting panels and CDNs:** many panels request certificates for you. If you also run your own client for the same names, the two may compete and double the number of orders.

## Don't do this

- **Revoke and reissue to "reset" the limit.** Revocation does not restore capacity.
- **Create new ACME accounts to get around the limit.** The domain and duplicate limits are global, and account creation has its own per-IP limit.
- **Switch to an untrusted workaround** such as serving a self-signed certificate on production while you wait. Keep the old certificate running instead, or temporarily use another ACME CA your client supports.
- **Keep a broken renewal job running every few minutes.** Fix it on staging and schedule renewals once or twice a day.