Errors and exceptions·续

Script startup exceeded memory limit

This means that you are doing work in the top-level scope of your Worker that allocates more than the memory limit (128 MB) of memory.

Inherit binding errors (10057)

An inherit binding copies a binding from an earlier version of your Worker. You can use it to keep secrets and other bindings without sending their values again. If an inherit binding cannot be resolved, the upload fails with error 10057. The API returns one error for each binding that fails.

The script upload endpoints, such as Upload Worker Module and Upload Version, inherit from the most recently uploaded version of your Worker. That version is not always the deployed version. These endpoints return error 10057 when:

  • version_id is set to anything other than "latest".
  • No earlier version exists, and the request sets bindings_inherit=strict.
  • The earlier version has no binding with the inherited name, and the request sets bindings_inherit=strict.

Without bindings_inherit=strict, these endpoints drop an inherit binding that cannot be resolved.

To inherit a binding from a specific version, use the Versions endpoints of the beta Workers API. These endpoints accept a version ID in version_id. They return error 10057 when:

  • version_id is not a version ID, a version ID prefix of at least eight characters, or "latest".
  • The version does not exist.
  • The version has no binding with the inherited name.

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<br>would be exceeded<br> 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:

  1. In the Cloudflare dashboard, go to the Workers & Pages page. Go to Workers & Pages ↗
  2. In Overview, select your Worker and review your Worker's metrics.

Worker Errors

The Errors by invocation status chart shows the number of errors broken down into the following categories:

Error Meaning
Uncaught Exception Your Worker code threw a JavaScript exception during execution.
Exceeded CPU Time Limits Worker exceeded CPU time limit or other resource constraints.
Exceeded Memory Worker exceeded the memory limit during execution.
Internal An internal error occurred in the Workers runtime.

The Client disconnected by type chart shows the number of client disconnect errors broken down into the following categories:

Client Disconnects Meaning
Response Stream Disconnected Connection was terminated during the deferred proxying stage of a Worker request flow. It commonly appears for longer lived connections such as WebSockets.
Cancelled The Client disconnected before the Worker completed its response.

Debug exceptions with Workers Logs

Workers Logs is a powerful tool for debugging your Workers. It shows all the historic logs generated by your Worker, including any uncaught exceptions that occur during execution.

To find all your errors in Workers Logs, you can use the following filter: $metadata.error EXISTS. This will show all the logs that have an error associated with them. You can also filter by $workers.outcome to find the requests that resulted in an error. For example, you can filter by $workers.outcome = "exception" to find all the requests that resulted in an uncaught exception.

All the possible outcome values can be found in the Workers Trace Event reference.

Debug exceptions from Wrangler

To debug your worker via wrangler 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 3rd party 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 floating promises (promises that are neither awaited, returned, nor passed to ctx.waitUntil()) may be canceled when the Worker invocation completes. A Worker invocation has not completed while it is still streaming a response body to the client. To run logging after the response is complete, pass the request promise to ctx.waitUntil(). For example:

export default {
    async fetch(request, env, ctx) {
        function postLog(data) {
            return fetch("https://log-service.example.com/", {
                method: "POST",
                body: data,
            });
        }

try {
            return await fetch(request);
        } catch (err) {
            // Without ctx.waitUntil(), the `postLog` function may or may not complete.
            ctx.waitUntil(postLog(err.stack));
            return new Response("Internal Server Error", { status: 500 });
        }
    },
};

Service Workers are deprecated

Service Workers are deprecated, but still supported. We recommend using Module Workers instead. New features may not be supported for Service Workers.

addEventListener("fetch", (event) => {
    event.respondWith(handleEvent(event));
});

async function handleEvent(event) {
    try {
        return await fetch(event.request);
    } catch (err) {
        // Without event.waitUntil(), the `postLog` function may or may not complete.
        event.waitUntil(postLog(err.stack));
        return new Response("Internal Server Error", { status: 500 });
    }
}

function postLog(data) {
    return fetch("https://log-service.example.com/", {
        method: "POST",
        body: data,
    });
}

Collect and persist Wasm core dumps

Configure the Wasm Coredump Service ↗︎ to collect coredumps from your Rust Workers applications and persist them to logs, Sentry, or R2 for analysis with wasmgdb ↗︎. Read the blog post ↗︎ for more details.

Go to origin on error

By using passThroughOnException(), a Workers application can 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.

ctx.passThroughOnException() forwards requests for unhandled exceptions in your Worker code, not for errors from the origin fetch(). When proxying requests to an origin, wrap fetch(request) in [try...catch](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch) and return a 5xx response on failure. If the origin fetch() throws after consuming the request body, passThroughOnException() cannot replay the body.

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);
    },
};

Service Workers are deprecated

Service Workers are deprecated, but still supported. We recommend using Module Workers instead. New features may not be supported for Service Workers.

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);
}

Was this helpful?

YesNo

On this page

Errors and exceptions·续 - 图1Docs

{"@context":"https://schema.org","@type":"TechArticle","@id":"https://developers.cloudflare.com/workers/observability/errors/#page","headline":"Errors and exceptions","description":"Review Workers errors and exceptions.","url":"https://developers.cloudflare.com/workers/observability/errors/","inLanguage":"en","image":"https://developers.cloudflare.com/workers/observability/errors/og.png?v=d4d7666e14bbf04d","dateModified":"2026-10-15","publisher":{"@type":"Organization","name":"Cloudflare","description":"One platform for your apps, agents, and workforce. Build, secure, and scale without managing infrastructure","url":"https://www.cloudflare.com/","sameAs":["https://github.com/cloudflare","https://www.linkedin.com/company/cloudflare","https://x.com/cloudflare"],"logo":{"@type":"ImageObject","url":"https://developers.cloudflare.com/logo.svg"},"address":{"@type":"PostalAddress","streetAddress":"101 Townsend St","addressLocality":"San Francisco","addressRegion":"CA","postalCode":"94107","addressCountry":"US"},"contactPoint":[{"@type":"ContactPoint","contactType":"Customer Support","url":"https://support.cloudflare.com/","availableLanguage":["English"]},{"@type":"ContactPoint","contactType":"Sales","url":"https://www.cloudflare.com/contact/","availableLanguage":["English"]}]},"isPartOf":{"@type":"WebSite","@id":"https://developers.cloudflare.com/#website","name":"Cloudflare Docs","url":"https://developers.cloudflare.com/"}}

description: Detect, group, and investigate recurring failures in Cloudflare Workers, then route issues to your team or coding agent. title: Issues image: https://developers.cloudflare.com/workers/observability/issues/og.png?v=70c1409b88ecfd49

Skip to content

Documentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/workers/llms.txt
Use this file to discover all available pages before exploring further.