Cloudflare error 1025 can show visitors a vague request to check back later. Cloudflare associates it with a Workers plan limit. Identify the Worker handling the failed address, then compare the failure time with account usage and the applicable allowance. The error alone does not establish which resource was exhausted or when it resets.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Identify the Worker and allowance involved
| Question | Evidence | Decision it supports |
|---|---|---|
| Which Worker handles this URL? | Matching route or custom domain | Locate the responsible service and account |
| What allowance was reached? | Plan and usage during the failure window | Confirm capacity rather than infer it |
| Why did demand rise? | Deployment and traffic timeline | Separate legitimate demand from accidental repeated work |
| Does recovery cover the feature? | Original request and Worker-dependent behavior | Verify the actual affected workflow |
Identify the Worker in the request path
Keep the affected hostname, page address, failure time, and complete error message. Review which Worker routes or custom domains handle that request. Some sites use a Worker across the entire domain, while others use one only for an API endpoint or a specific feature.
For example, a public article might depend on a Worker added for request handling. If that Worker stops serving requests, visitors can lose access to the article even though the hosting server remains available. The route explains how the limit could affect the page; it does not tell you which allowance was reached.
Make sure you are looking at the Cloudflare account that owns the relevant Worker. A plan shown for a different domain or account is not evidence about this service’s available usage.
Compare the failure time with usage information
Keep a short incident record: hostname, path, failure time with time zone, Worker identity, observed usage and displayed limit. Compare the outage window with the current totals. A plan allowance for another account, or a screenshot taken long after recovery, cannot alone establish the cause.
Review the Workers dashboard for the applicable plan, usage, and error information. Keep the failure window in view rather than relying only on a current total. A burst earlier in the day may explain an outage that is no longer happening when you inspect the site.
The purpose is to establish what resource or allowance is involved and whether usage reached its boundary. Avoid treating every limit as something that automatically resets after a short wait. The behavior depends on the applicable plan and limit, and an upgrade is not a universal answer to every Worker error.
A recent deployment, traffic campaign, or automated integration can help explain a change in demand. Record the timing and compare it with the observed usage. If the pattern begins immediately after a code change, the maintainer should review that change as well as the account allowance.
Decide whether demand or design needs attention
Check repeated integration calls and recent code changes before choosing capacity changes. If legitimate traffic exceeds the applicable allowance, the account owner can evaluate the current plan options and cost. If a deployment multiplied requests unexpectedly, reviewing the design addresses the source of growth. Keep the Worker’s access and routing responsibilities intact.
If the workload is legitimate and the plan allowance is the issue, the account owner can review the current Workers plan options. Cloudflare’s 1025 support page recommends a Workers plan upgrade, but its terminology should be checked against the current options shown for your account before making a purchase.
If usage is unexpectedly high, investigate why. A repeated automated call or a feature issuing more requests than intended deserves a design review. Buying more capacity without understanding that pattern may leave the same behavior in place at a larger scale.
Before removing the Worker from a route, establish what it does. A Worker can provide access decisions or other essential behavior. A public page becoming reachable after a bypass would not prove that the site is operating correctly or safely.
Verify recovery with the original page
After the responsible administrator makes a supported change, open the exact address that failed. Check the intended content and any feature that depends on the Worker. Keep a record of the request time so that it can be compared with current usage and error information.
Try another request covered by the same route and one outside it. This helps establish the scope of recovery. A homepage outside the affected route can load while the original feature still fails.
If 1025 continues despite usage appearing within the applicable limits, give Cloudflare support the affected domain, Worker identity, plan context, failure time, and sanitized error evidence. A specific account investigation is more useful than repeatedly refreshing a vague “check back later” message.
Keep a note of the confirmed limit and the decision made. That turns the outage into an operational reference for future traffic changes and helps distinguish a capacity issue from a new application error.
Reference: Cloudflare error 1025 documentation.
Record the confirmed limit and recovery
Retest the exact failed request, another request handled by the Worker, and an unrelated route. Confirm the intended content and feature behavior. Document the allowance actually identified, the chosen correction and the request times. If usage does not explain the failure, send that evidence to the provider rather than repeatedly waiting without a confirmed reset rule.