What is the crt.sh rate limit?

crt.sh does not publish a rate limit. Empirically it is roughly 5 requests per minute per source IP for the JSON output endpoint. The limit can drop further when the backend Postgres is under load — manifesting as 502 errors or empty result sets rather than explicit 429s.

Does crt.sh return 429 when rate limited?

Usually not. crt.sh tends to return 502 Bad Gateway, an empty array, or a long-running query that times out. There is no Retry-After header. The community workaround is to sleep 12-15 seconds between requests as a baseline.

How do I bypass the crt.sh rate limit?

You don't bypass it — Sectigo runs crt.sh as a public good and IP rotation is rude. Real options: (1) cache aggressively client-side, (2) batch wildcard queries instead of per-subdomain, (3) use an alternative service that publishes its own quotas (CT Radar, Censys, Cert Spotter), or (4) self-host a CT log mirror.

crt.sh rate limit — what we actually know

crt.sh has no published rate limit, but anyone who has tried to script against it has hit one. Here is the consensus from years of community testing, and a few ways to keep your recon pipeline working.

The numbers, as best we can tell

~5 requests per minute per source IP for the JSON endpoint, holding steady for years across community reports.
No 429. The server returns 502 Bad Gateway, empty arrays, or long-hanging queries instead.
No Retry-After. Backoff is up to you. ~12-15s baseline between requests is the community rule of thumb.
Heavier penalties for wildcards. Wildcard queries (%.example.com) consume more query budget and hit the limit faster.
Asymmetric: the HTML interface usually responds while the JSON endpoint refuses, suggesting separate query paths.

Why the limit exists

crt.sh queries a single PostgreSQL instance against several billion rows. Concurrent expensive queries from one client can starve the entire service for everyone else. Sectigo provides crt.sh as a free public good — the rate limit exists to keep the service available, not to monetize it.

How to keep your pipeline working

1. Cache aggressively

CT data only grows. Once you have a domain's certificate history, only new entries matter. Use ETag/conditional requests against your own cache, not against crt.sh.

2. Prefer wildcard queries over per-subdomain loops

One query for %.example.com costs less than 200 queries for individual subdomains, even though wildcards have higher per-query cost.

3. Use a service with published quotas

CT Radar offers 100 searches/day on the free tier with explicit 429 + Retry-After headers when you exceed it. Pro tier lifts to 10K/day. Censys, Cert Spotter, and others have similar published quotas.

4. Self-host a CT mirror

If your volume justifies it, consume CT logs directly using certspotter (open source) and index them yourself. This is what crt.sh, Censys, and CT Radar all do internally — there is no shortcut.

Hit the crt.sh limit? Try CT Radar

100 searches per day on the free tier. Documented quotas. Real 429 responses. No mystery.

Search now →