Error 1101 — Worker threw exception
Cloudflare Error 1101 means your Worker threw an uncaught exception during request handling. The request fails with a 500 response, and if you're using Sentry or console.log-based logging, you likely see nothing — the crash happened too fast for your SDK to fire.
Common causes
- ▸Uncaught exception in your fetch handler (TypeError, ReferenceError, SyntaxError at runtime)
- ▸Calling an undefined function or accessing a property of undefined/null
- ▸JSON.parse() on malformed input without try/catch
- ▸Accessing a Cloudflare binding (env.X) that isn't configured in wrangler.jsonc
- ▸Throwing inside an async function without catching the rejection
- ▸Module-level code that throws during Worker initialization (syntax errors, bad imports)
Symptoms
- •Users see a 500 error or blank page
- •Cloudflare dashboard shows 'Error 1101' in the Workers > Logs tab
- •Your Sentry dashboard shows nothing — the SDK never fired
- •console.log statements before the crash line are missing from Cloudflare's log explorer
- •The error is intermittent or only happens on certain request paths
How to fix it
- ✓Wrap your fetch handler body in try/catch and log the error: try { ... } catch (e) { logger.logError(e); throw e; }
- ✓Validate all env bindings exist before using them: if (!env.MY_BINDING) throw new Error('MY_BINDING not configured')
- ✓Use optional chaining (obj?.prop) instead of direct property access on untrusted input
- ✓Wrap JSON.parse() calls in try/catch and return a 400 on malformed input
- ✓Deploy a Tail Worker (like FlareLog) that captures execution outcomes out-of-band — it sees crashes your SDK can't
- ✓Add source maps to your Worker build for readable stack traces
- ✓Test with wrangler dev --local to catch errors before deploying
How FlareLog helps
FlareLog's Tail Worker runs out-of-band, after your Worker finishes (or crashes). It receives the execution outcome from Cloudflare's runtime — including the uncaught exception, CPU time, and duration — even when your Worker dies on line 1. You see the full stack trace, the request that triggered it, and the cost impact in your FlareLog dashboard. No SDK required.
Catch Error 1101 with FlareLog →FAQ
Why doesn't Sentry catch Error 1101?
Sentry's Cloudflare Workers SDK wraps your fetch handler and catches exceptions thrown during request handling. But Error 1101 can occur before your fetch handler registers (during module initialization) or when the runtime kills the Worker for CPU/memory limits. In both cases, Sentry's captureException never fires because the Worker is already dead. FlareLog's Tail Worker runs after your Worker finishes and receives the outcome from Cloudflare's runtime — so it captures crashes that happen before, during, and after your code runs.
How do I find which request caused Error 1101?
In Cloudflare's dashboard, you see the error but not the request URL or headers. With FlareLog's Tail Worker, each crash log includes the full request: method, URL, headers, and the exact exception with stack trace. You can search by traceId to correlate the crash with upstream/downstream requests.
Can I prevent Error 1101 entirely?
Not entirely — bugs happen. But you can reduce frequency: (1) wrap your handler in try/catch and return a graceful 500 instead of crashing, (2) validate all inputs and env bindings, (3) add unit tests for edge cases, (4) use TypeScript to catch null/undefined access at compile time, (5) deploy a Tail Worker so you see crashes immediately and can fix them before users report them.
Does Error 1101 affect my Cloudflare bill?
Yes — each errored request still counts as a Worker invocation. If 10% of your traffic hits Error 1101, you're paying for 10% more invocations than you need. FlareLog's cost burn alerts can notify you when error rates spike, so you can fix the bug before it inflates your bill.