Cloudflare Docs
Workers
Edit this page
Report an issue with this page
Log into the Cloudflare dashboard
Set theme to dark (⇧+D)

Errors and exceptions

Review Workers errors and exceptions.

​​ Error pages generated by Workers

When a Worker running in production has an error that prevents it from returning a response, the client will receive an error page with an error code, defined as follows:

Error codeMeaning
1101Worker threw a JavaScript exception.
1102Worker exceeded CPU time limit.
1103The owner of this worker needs to contact Cloudflare Support
1015Worker hit the burst rate limit.
1019Worker hit loop limit.
1021Worker has requested a host it cannot access.
1022Cloudflare has failed to route the request to the Worker.
1024Worker cannot make a subrequest to a Cloudflare-owned IP address.
1027Worker exceeded free tier daily request limit.
1042Worker tried to fetch from another Worker on the same zone, which is unsupported.

Other 11xx errors generally indicate a problem with the Workers runtime itself. Refer to the status page if you are experiencing an error.

​​ Loop limit

A Worker cannot call itself or another Worker more than 16 times. In order to prevent infinite loops between Workers, the CF-EW-Via header’s value is an integer that indicates how many invocations are left. Every time a Worker is invoked, the integer will decrement by 1. If the count reaches zero, a 1019 error is returned.

​​ Errors on Worker upload

These errors occur when a Worker is uploaded or modified.

Error codeMeaning
10006Could not parse your Worker’s code.
10007Worker or workers.dev subdomain not found.
10015Account is not entitled to use Workers.
10016Invalid Worker name.
10021Validation Error. Refer to Validation Errors for details.
10026Could not parse request body.
10035Multiple attempts to modify a resource at the same time
10037An account has exceeded the number of Workers allowed.
10026Could not parse request body.
10052A binding is uploaded without a name.
10054A environment variable or secret exceeds the size limit.
10055The number of environment variables or secrets exceeds the limit/Worker.
10056Binding not found.
10068The uploaded Worker has no registered event handlers.
10069The uploaded Worker contains event handlers unsupported by the Workers runtime.

​​ Validation Errors (10021)

The 10021 error code includes all errors that occur when you attempt to deploy a Worker, and Cloudflare then attempts to load and run the top-level scope (everything that happens before your Worker’s handler is invoked). For example, if you attempt to deploy a broken Worker with invalid JavaScript that would throw a SyntaxError — Cloudflare will not deploy your Worker.

Specific error cases include but are not limited to:

​​ Script startup exceeded CPU time limit

This means that you are doing work in the top-level scope of your Worker that takes more than the startup time limit (400ms) of CPU time.

This is usually a sign of a bug and/or large performance problem with your code or a dependency you rely on. It’s not typical to use more than 400ms of CPU time when your app starts. The more time your Worker’s code spends parsing and executing top-level scope, the slower your Worker will be when you deploy a code change or a new isolate is created.

This error is most commonly caused by attempting to perform expernsive initialization work directly in top level (global) scope, rather than either at build time or when your Worker’s handler is invoked. For example, attempting to initialize an app by generating or consuming a large schema.

To analyze what is consuming so much CPU time, you should open Chrome DevTools for your Worker and look at the Profiling and/or Performance panels to understand where time is being spent. Is there something glaring that consumes tons of CPU time, especially the first time you make a request to your Worker?

​​ Runtime errors

Runtime errors will occur within the runtime, do not throw up an error page, and are not visible to the end user. Runtime errors are detected by the user with logs.

Error messageMeaning
Network connection lostConnection failure. Catch a fetch or binding invocation and retry it.
Memory limit
would be exceeded
before EOF
Trying to read a stream or buffer that would take you over the memory limit.
daemonDownA temporary problem invoking the Worker.

​​ Identify errors: Workers Metrics

To review whether your application is experiencing any downtime or returning any errors:

  1. Log in to the Cloudflare dashboard and select your account.
  2. In Account Home, select Workers & Pages.
  3. In Overview, select your Worker and review your Worker’s metrics.

​​ Debug exceptions

After you have identified your Workers application is returning exceptions, use wrangler tail to inspect and fix the exceptions.

Exceptions will show up under the exceptions field in the JSON returned by wrangler tail. After you have identified the exception that is causing errors, redeploy your code with a fix, and continue tailing the logs to confirm that it is fixed.

​​ Set up a logging service

A Worker can make HTTP requests to any HTTP service on the public Internet. You can use a service like Sentry to collect error logs from your Worker, by making an HTTP request to the service to report the error. Refer to your service’s API documentation for details on what kind of request to make.

When using an external logging strategy, remember that outstanding asynchronous tasks are canceled as soon as a Worker finishes sending its main response body to the client. To ensure that a logging subrequest completes, pass the request promise to event.waitUntil(). For example:

export default {
async fetch(request, env, ctx) {
function postLog(data) {
return fetch("https://log-service.example.com/", {
method: "POST",
body: data,
});
}
// Without ctx.waitUntil(), the `postLog` function may or may not complete.
ctx.waitUntil(postLog(stack));
return fetch(request);
}
}
addEventListener("fetch", (event) => {
event.respondWith(handleEvent(event));
});
async function handleEvent(event) {
// ...
// Without event.waitUntil(), the `postLog` function may or may not complete.
event.waitUntil(postLog(stack));
return fetch(event.request);
}
function postLog(data) {
return fetch("https://log-service.example.com/", {
method: "POST",
body: data,
});
}

​​ Go to origin on error

By using event.passThroughOnException, a Workers application will forward requests to your origin if an exception is thrown during the Worker’s execution. This allows you to add logging, tracking, or other features with Workers, without degrading your application’s functionality.

export default {
async fetch(request, env, ctx) {
ctx.passThroughOnException();
// an error here will return the origin response, as if the Worker wasn't present
return fetch(request);
}
}
addEventListener("fetch", (event) => {
event.passThroughOnException();
event.respondWith(handleRequest(event.request));
});
async function handleRequest(request) {
// An error here will return the origin response, as if the Worker wasn’t present.
// ...
return fetch(request);
}
  • Log from Workers - Learn how to log your Workers.
  • Logpush - Learn how to push Workers Trace Event Logs to supported destinations.