Cloudflare: Error 1015: You are being rate limited
Last verified
Error 1015: You are being rate limitedWhat it means
Error 1015 means a rate limiting rule the site owner configured in Cloudflare counted too many requests from you within its time window. Cloudflare's documentation describes the cause as the website owner having configured rate limiting rules that restrict how many requests a visitor can make. Rate limiting rules commonly respond with HTTP 429, although an owner can configure the response.
For automation, 1015 is the clearest possible signal: you are sending requests faster than the site allows. Rules usually count per IP, but can also count per header, cookie, API key or path, and the block lasts for a mitigation period the owner chose (often seconds to minutes, sometimes longer). Retrying during that period can extend it.
For the site owner, 1015 is working as designed. If real users see it, the threshold is too low or the counting characteristics are too broad, for example many users behind one office NAT sharing an IP.
What it looks like
HTTP/1.1 429 Too Many Requests
Server: cloudflare
Retry-After: 60
... Error 1015 ... You are being rate limited ...Why it happens
- A script, crawler or browser automation sends requests faster than the rule's threshold.
- Many users or jobs share one IP (office NAT, CI runner, proxy), so their combined traffic trips the rule.
- A client retries immediately after errors, multiplying traffic.
- The owner set a low threshold on a sensitive path such as login or search.
How to fix it
- Visitors: wait and try again later, which is exactly Cloudflare's recommended resolution.
- Automation: stop sending, then resume at a much lower, steady rate with backoff and jitter.
- Cache responses and avoid fetching the same URL repeatedly.
- If you need higher volume, ask the site owner for an API, export, or an agreed rate.
- Site owners: review the rule's threshold, period and counting characteristics, and whether shared IPs are being grouped.
How to stop it recurring
Integrators: build a per-host rate limiter into every job and honor Retry-After; see HTTP 429. Site owners: base thresholds on real traffic data, count by API key or session where possible, and use a challenge instead of a block when real users might be affected.
Official documentation: developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1015. See all Cloudflare error messages.
Related errors
Definitions
- CAPTCHACAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a challenge-response m
- Cloudflare Bot ManagementCloudflare Bot Management is the set of Cloudflare features (Bot Fight Mode, Super Bot Fight Mode and the Ente
- Cloudflare TurnstileCloudflare Turnstile is Cloudflare's free CAPTCHA replacement: a widget that runs invisible browser checks, is
- User AgentA user agent is a string that browsers send with every HTTP request identifying the browser type, version, and
- Rate LimitingRate limiting is a technique that controls the number of requests a client can make to a server within a given
Quick answers
What does "Error 1015: You are being rate limited" mean in Cloudflare?
Error 1015 means a rate limiting rule the site owner configured in Cloudflare counted too many requests from you within its time window. Cloudflare's documentation describes the cause as the website owner having configured rate limiting rules that restrict how many requests a visitor can make. Rate limiting rules commonly respond with HTTP 429, although an owner can configure the response.
How do I fix "Error 1015: You are being rate limited"?
1. Visitors: wait and try again later, which is exactly Cloudflare's recommended resolution. 2. Automation: stop sending, then resume at a much lower, steady rate with backoff and jitter. 3. Cache responses and avoid fetching the same URL repeatedly. 4. If you need higher volume, ask the site owner for an API, export, or an agreed rate. 5. Site owners: review the rule's threshold, period and counting characteristics, and whether shared IPs are being grouped.
Retries and timeouts without writing the loop
Autonoly's HTTP Request node and browser steps have per-node retries, timeouts and continue-on-fail, so a transient 429 or 503 can back off instead of failing the run. It has no proxies or IP rotation: if a site blocks automated traffic, that block applies to Autonoly too.
Also see Error handling in workflows.