What are Let's Encrypt rate limits?

Let's Encrypt rate limits cap how fast one account or one domain can obtain certificates from a free, automated CA that issues millions of certificates a day. The limits exist to keep runaway automation from exhausting the service, and nearly every team that automates issuance meets one eventually — usually from a deploy loop rather than real demand.

The limit that bites hardest caps certificates per registered domain per week: fifty new certificates across all of example.com and its subdomains in any rolling seven days. Teams that issue one certificate per customer subdomain hit it at onboarding spikes; the standard designs around it are a wildcard certificate or spreading issuance over days. Separate from that, a duplicate-certificate limit (five per week for the same exact set of names) is the one a crashed renewal loop trips: reissue the same certificate five times and the sixth attempt is refused.

Two properties keep the limits from being as scary as they sound. Renewals are deliberately exempt from the per-domain cap — a renewal counts only against the duplicate limit, so a domain with hundreds of live certificates keeps renewing them freely. And the limits are rolling windows, not monthly quotas: when a request is refused, the response says so explicitly, and waiting out the window always works. There is also a per-account cap on new orders and a limit on failed validations per hour, which is the one that turns a misconfigured DNS record into an enforced pause.

The operational rules that follow: test against Let's Encrypt's staging environment, which has far higher limits, so experiments never spend production quota; keep and reuse the certificates you obtain rather than reissuing on every deploy; and alert on issuance failures, because a rate-limited renewal that retries silently for days becomes an expired certificate on a schedule you did not choose.