Does the 50-certificates-per-week limit block custom domains?

Rarely. That limit is per registered domain, and each customer domain (acme.com, globex.io) is a different registered domain. You would need 50 certificates for one customer's single domain in a week to hit it. The limits that actually bite at scale are account-level.

What Let's Encrypt limit is most likely to break a large fleet?

The failed-validation / new-orders pressure caused by retry loops. A customer sets DNS, it has not propagated, issuance fails, and aggressive retries pile up failed authorizations across your account. Multiply by many customers configuring at once and you throttle yourself.

How do I avoid Let's Encrypt rate-limit problems?

Do not attempt issuance until DNS resolves to you, back off exponentially on failure, cache negative results so you do not retry on every request, and keep a second ACME provider as a fallback. Always re-check the current published limits before tuning.

Let's Encrypt Rate Limits at Scale

Which Let's Encrypt rate limits actually bite when you issue certificates for thousands of customer domains, the math behind them, and the mitigations that work.

Issuing SSL for one domain is trivial. Issuing for a thousand customer domains that all get configured on the same launch afternoon is where Let's Encrypt rate limits turn into a self-inflicted outage. Here is which limits actually matter at scale, the math behind them, and the mitigations that work — from running this across 5,000+ domains.

Let's Encrypt's exact limits change over time. The numbers below are the well-known ones as of July 2026; treat them as shape, not gospel, and re-read the current rate-limit page before you tune retry logic.

The limit everyone worries about (and shouldn't)

The famous one is roughly 50 certificates per registered domain per week. For custom domains this almost never bites, because registered domain means the billable eTLD+1 — acme.com, globex.io. Every customer brings a different one. To hit the cap you would need 50 issuances for a single customer's single domain in a week. If you see that, you have a renewal loop bug, not a scale problem.

The limits that actually bite

These are account-level, and they are triggered by failure, not success:

Failed validations — there is a cap on failed authorizations per account, per hostname, per hour. A domain whose DNS is not ready yet fails validation; retry it hard and you exhaust the budget fast.
New orders / new authorizations — high-frequency order creation across your whole account is throttled. Hundreds of customers configuring at once, each retrying, compounds.
Duplicate certificate — repeatedly ordering the identical set of names (same retry, same host) is limited separately.

The pattern is always the same: one broken domain generating dozens of failed orders, multiplied by many customers. It is not the count of your domains, it is the count of your retries against domains that are not ready.

The math of a launch spike

Say 300 customers configure domains during a launch. Suppose 20% set DNS incorrectly or too early. That is 60 domains failing validation. If your retry logic tries every 30 seconds for 10 minutes, each failing domain generates ~20 failed authorizations — 1,200 failed validations in ten minutes, all against one ACME account. That is how you throttle issuance for the 240 customers who did everything right.

The mitigations that work

Gate on DNS. Never attempt issuance until the hostname actually resolves to your edge. Check first, issue second. This alone removes most failures.
Back off exponentially with a ceiling, per hostname — not a fixed fast retry.
Cache negatives. A host that just failed should not trigger another attempt on the next request that comes in.
Spread and queue issuance instead of stampeding at launch.
Keep a fallback CA. A second ACME provider (for example ZeroSSL) means one CA incident or limit is not a hard stop.

Why this is the reason people stop self-hosting

Getting issuance right is not one setting — it is a small system: DNS pre-checks, backoff, negative caching, queueing, multi-CA fallback, and observability on the whole funnel (attempted → DNS-ready → issued → served). Most teams underestimate it until a launch throttles them. We built it once and packaged it; the honest build-vs-buy math is in build vs buy and cnames.dev vs self-hosting Caddy on-demand TLS. The broader production picture is in how we run SSL for 5,000+ domains. Check any cert with the SSL checker.

Let's Encrypt rate limits at scale: what breaks at 1,000 domains