Covers SQLITE_BUSY caused by two or more write requests colliding on the same D1 database (including a Worker request racing a Cron Trigger), and by a single invocation issuing many unbatched writes in a row. Does not cover SQLITE_BUSY from an actually-stuck transaction left open by a crashed process, or D1's separate CPU-time/memory-limit resets — those return different, more specific error messages.
Covers the D1-specific per-invocation request cap being hit by an N+1 query pattern or by combining many D1 calls with other subrequests in one invocation. Does not cover the general Workers subrequest limit for fetch()-only Workers with no D1 involved (see Workers platform limits), and does not cover D1's separate CPU-time or memory-limit resets, which return different error text entirely.
Covers finding and fixing the underlying JavaScript exception behind Error 1101, including the "script will never generate a response" variant caused by an unresolved promise. Does not cover Error 1102 (CPU time limit exceeded — a resource limit, not a thrown exception) or Error 1015 (rate limiting) — those have separate, more specific causes and remedies.
Covers genuine CPU-time exhaustion (heavy synchronous computation) and distinguishes it from a request that's merely slow because it's waiting on a subrequest — waiting time never counts toward CPU time, so that case needs a different fix entirely. Does not cover memory-limit resets (a different error, "Exceeded Memory") or the free-plan daily request cap (Error 1027).
Covers the module-level-caching anti-pattern for I/O objects (Request/Response/streams/database clients) in Workers. Does not cover the Cache API, which is the correct, supported way to cache actual HTTP responses across requests — this playbook is specifically about accidentally reusing the live object rather than its data.
Covers the expected, documented behaviour that a code update terminates a Durable Object's WebSockets, and gradual deployments extending the window this can happen in. Does not cover WebSocket drops unrelated to deploys (idle timeouts, client network loss, or missing ping/pong handling) — rule those out first if the disconnects don't line up with a deploy.
Covers the two things this error almost always traces back to — a connection string or driver entry point that isn't the one meant for this runtime, and isolating whether the failure is Worker-specific. Does not cover general Postgres server-side connection issues once the WebSocket itself connects successfully — those are covered by the general Postgres playbooks.