Cloudflare Error 1015 means a website has blocked a request because a rate limit was exceeded. The block is intentional and does not, by itself, mean that the origin server is down. Visitors should stop rapid retries and wait for the block to expire; site owners should examine the rule and traffic pattern before deciding whether the threshold is wrong.

A user refreshing a page, an application polling an API, and an automated job can generate very different request rates. The correct fix depends on which requests were counted and whether they were legitimate. A visitor can reduce their own requests, but only the site owner or an authorized administrator can change the website's rate limiting policy.

Confirm the Error and Find the Matching Event

Check that the page shows Error 1015 with the message “You are being rate limited.” Cloudflare also uses code 1015 for an “Unable to purge” cache error. That message concerns an administrator's cache operation and needs a different investigation from a blocked website visit.

Record the affected URL, a screenshot, the time with its time zone, and the Ray ID if shown. Note the action that led to the error, such as opening a page or submitting a form. Send these details to the site owner if you need help; a Ray ID alone does not establish which rule blocked the request.

As the owner, select the correct site in the Cloudflare dashboard and open Security, then Analytics, then the Events tab. Filter by the reported time and available request details. Match the hostname and path, then inspect the action, rate limiting rule, and client information. Because Security Events can contain sampled data, narrow the time window or check other available logs if you cannot find the reported block.

Stop Repeated Requests and Allow the Block to Expire

If you are a visitor, pause the activity that led to the message. Do not refresh the page in a tight loop or repeatedly resubmit a form; more requests can prolong the block or trigger it again. Wait for any stated duration before making one normal request. If no waiting time is shown, pause before trying again and ask the site owner for help if ordinary use remains blocked.

If you run a client or automation that you control, stop concurrent retries and inspect its request schedule. Limit the number of retries and wait longer between attempts when retrying is appropriate. Honor any server-provided retry guidance where available, and avoid sending duplicate state-changing requests without checking whether the previous attempt succeeded. A lower rate from the client can be the appropriate fix even when the owner's rule is functioning correctly.

Do not rotate IP addresses or change identities to bypass a site's limit. Such tactics can obscure the diagnosis and defeat a control that protects login forms and APIs from abuse. If legitimate usage needs a higher allowance, discuss that requirement with the site owner.

Review the Rate Limiting Rule

Open the matched rate limiting rule on the Security rules page. Review the request filter, counting characteristics, requests per period, action, and mitigation duration together. The counting period is the window used to measure the request rate; the mitigation duration is how long the configured action applies after the limit is exceeded. Changing one does not mean that the other has changed.

Counting characteristics determine which requests share a counter. With IP-based counting, several clients using one public address can contribute to the same count. Check whether affected users share an office network or whether approved integrations send requests through the same public IP address. Other characteristics may be available depending on the plan.

Check whether a page load generates several API calls or whether an application immediately retries failed work. These requests can consume an allowance even when the visitor clicks only once. Compare traffic for the affected endpoint and counting characteristics, rather than comparing one user's clicks with the total traffic for the entire site.

With a fixed-duration block, Cloudflare continues applying the block for that duration even if the later request rate falls. Slowing down therefore does not necessarily remove an already active block immediately. Use the active rule settings rather than assuming a universal waiting time.

Adjust the Rule for Legitimate Traffic

If the rule is correctly blocking automated abuse, retain it and fix the client sending too many requests. If it is blocking intended use, narrow the match to the endpoint that actually needs protection, choose suitable counting characteristics, or adjust the threshold and period to measured legitimate demand. Review normal bursts as well as sustained traffic so the change addresses the pattern that caused the block.

Evaluate the request count and counting period as a pair. For example, a threshold of 120 requests per 60 seconds is stricter over time than 120 requests per 10 seconds. Increasing only the period does not automatically grant more access. These example values illustrate the difference; they are not recommended settings for every application.

Use traffic records to compare ordinary requests with the unwanted rate the rule should catch. Enterprise accounts can use Request rate analysis in Security Analytics to examine the rate distribution for selected traffic. If that view is unavailable, use the request records available to your account and application. A threshold far above the abusive rate may stop protecting the endpoint.

Make one documented change at a time and keep the protective purpose of the rule. Raising every limit across the site, disabling rate limiting, or granting a broad bypass can expose sensitive endpoints. Save the previous settings, then deploy the intended adjustment. If a partner needs a separate allowance, check overlapping rules too; adding a second rule does not automatically exempt that client from the first.

Retest with Normal Traffic

After the change is deployed and the current block has expired, repeat the affected operation at its normal rate. Confirm that the application completes the request. A successful request may not appear in Security Events, which focuses on traffic acted on or flagged by security features, so consider the application result and available traffic logs together.

Assess the remaining protection using approved test traffic and rule records. Do not generate an uncontrolled burst against a production endpoint. Rate limiting counters can take a short time to update, so a rule is not a guarantee that exactly the configured number of requests reaches the origin.

Monitor later blocks and application load. If legitimate use is still denied, capture the new request details and identify the responsible rule before making another change. If the adjustment admits more traffic than intended, restore the previous settings and revise the change.