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 code | Meaning |
---|---|
1101 | Worker threw a JavaScript exception. |
1102 | Worker exceeded CPU time limit. |
1103 | The owner of this worker needs to contact Cloudflare Support |
1015 | Worker hit the burst rate limit. |
1019 | Worker hit loop limit. |
1021 | Worker has requested a host it cannot access. |
1022 | Cloudflare has failed to route the request to the Worker. |
1024 | Worker cannot make a subrequest to a Cloudflare-owned IP address. |
1027 | Worker exceeded free tier daily request limit. |
1042 | Worker 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 code | Meaning |
---|---|
10006 | Could not parse script body. |
10007 | Script or workers.dev subdomain not found. |
10015 | Account is not entitled to use Workers. |
10016 | Invalid script name. |
10026 | Could not parse request body. |
10035 | Multiple attempts to modify a resource at the same time |
10037 | An account has exceeded the number of Workers scripts allowed. |
10026 | Could not parse request body. |
10052 | A binding is uploaded without a name. |
10054 | A environment variable or secret exceeds the size limit. |
10055 | The number of environment variables or secrets exceeds the limit/Worker. |
10056 | Binding not found. |
10068 | The uploaded script has no registered event handlers. |
10069 | The uploaded script contains event handlers unsupported by the Workers runtime. |
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 message | Meaning |
---|---|
Network connection lost | Connection 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. |
daemonDown | A temporary problem invoking the Worker. |
Identify errors: Workers Metrics
To review whether your application is experiencing any downtime or returning any errors:
- Log in to the Cloudflare dashboard and select your account.
- In Account Home, select Workers & Pages.
- 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);
}
Related resources
- Log from Workers - Learn how to log your Workers.
- Logpush - Learn how to push Workers Trace Event Logs to supported destinations.