Let's Encrypt rate limits: the operator flowchart

Let's Encrypt is moving default certificate lifetime from 90 days to 64, then to 45, over the next two years. In its own words, this will "ultimately double the number of certificate renewal requests each day." A limit that rarely mattered at a 90-day cadence gets hit twice as often at 45. Here is which specific limit you actually run into, why, and how long until it clears, plus the one mechanism that sidesteps the whole problem for most automated setups.

Which limit did you actually hit

The error message tells you which one. "too many certificates already issued for exact set of domains" is the Duplicate Certificate limit, almost always a retry loop reissuing for names that have not changed. A rate-limit error mentioning the registered domain broadly, not an exact set, is the per-domain limit. An error at the order-creation step before any names are even validated is the per-account order limit.

Why 2026 makes this more likely, not less

The lifetime shortening is real and already announced. Let's Encrypt confirmed the 90-to-64-to-45-day transition and stated plainly that subscribers don't need to change their own rate-limit configuration, the limits themselves are not moving. What changes is how often a normal renewal cycle brushes up against them: a 45-day cert renews roughly every 30 days instead of every 60, so a fleet that issues certificates for many subdomains, or a retry loop that used to have two months to go unnoticed before hitting the Duplicate Certificate limit, now has about half that.

This is not a hypothetical stress case. On 8 May 2026, Let's Encrypt halted all certificate issuance for roughly two and a half hours after a cross-signed root certificate linking its Generation X and Generation Y roots turned out to be missing required Extended Key Usage fields. Let's Encrypt's own status page confirmed the rollback and fix. Issuance itself is not infallible, which is exactly why a retry storm colliding with a shortened renewal cycle is worth planning for rather than discovering during an outage.

The mechanism most automation already has

Renewals recognized through ACME Renewal Information (ARI) are exempt from rate limits entirely, regardless of how short the certificate lifetime gets. A client that supports ARI checks with Let's Encrypt for the actual optimal renewal window rather than guessing off the raw expiry date, and a renewal made through that path does not count against the Duplicate Certificate or per-domain limits the way a manually triggered reissue does. For the full mechanics of how ARI works and why it matters as a monitoring signal in its own right, see ACME Renewal Information: the monitoring blind spot. The short version for this post: confirm the ACME client in use actually supports ARI (recent certbot and most modern clients do) before assuming rate limits are a real constraint on renewal.

What to actually do at each limit

• Hit the Duplicate Certificate limit: stop retrying immediately, this is the mistake that makes the problem worse: a script that reissues on every failure eats through the 5-per-168-hour budget in minutes, turning a transient error into a genuine outage of your own making. Check whether the ACME client supports and is using ARI. If not, wait out the rolling window rather than forcing more attempts, and fix whatever is triggering the retries (a misfiring cron, a webhook that fires twice) before the window clears
• Hit the per-registered-domain limit (50 certificates per registered domain per rolling week): this usually means genuinely high subdomain issuance volume, multi-tenant SaaS onboarding customers with their own subdomains, or a CI pipeline spinning up preview environments faster than certificates can be issued for them. A wildcard certificate for the relevant subdomain pattern sidesteps repeated per-subdomain issuance entirely, though that trades in a different set of operational risks (a single private key covering every subdomain) worth weighing on its own terms rather than reaching for by default
• Hit the per-account order limit (300 new orders per account per rolling 3 hours): this is almost always a bug, not real volume, a loop or a misfiring batch job creating orders faster than certificates are actually needed, sometimes from a deploy pipeline retrying a failed step without backing off. Fix the automation before retrying against production; raising request volume against the same broken loop does not fix a loop, it just burns through the budget faster
• Testing changes to issuance automation: Let's Encrypt's staging environment carries much higher limits specifically so a client integration, a renewal script, or a new automation pipeline can be run repeatedly while debugging without touching production quota at all. Staging certificates are not trusted by browsers, so they are useless for a live site, but for validating that the automation itself behaves correctly before pointing it at production, every experiment against the real environment instead spends real, limited budget you may need later that same week

WebPixie's Certificates Manager shows every certificate public Certificate Transparency logs have recorded for a domain, which is useful after a rate-limit-driven retry storm to confirm exactly what was actually issued versus what a script attempted. It reads CT logs; it does not issue certificates or manage rate limits itself.