Cloudflare Error 1102

[NCHILLC]

Measured it. wrangler tail caught a failing invocation, and it settles both questions.

outcome: exceededCpu
cpuTime: 10        wallTime: 13
exception: "Worker exceeded CPU time limit."
url: /login        status: 503

Across 45 requests: 43 ok, 1 exceededCpu (one request never reached the Worker). The CPU distribution:

  | cpuTime -- | -- Warm requests (39) | 5–31 ms Cold starts (5) | 118, 149, 178, 180, 191 ms The failure | 10 ms — exactly the Free plan's documented limit

Two corrections to what I told you earlier, both of which change the decision: the startup budget is 1 second, not the 400 ms I said, and it's not what you're hitting. And I said upgrading to Paid might not help — that was wrong. It's the per-request CPU limit, which your doc link puts at 10 ms on Free and 30 s on Paid. That's a 3,000× difference, and it's the whole problem.

Your app uses 5–31 ms of CPU on a warm login page and 120–190 ms on a cold one. It is over the Free budget on essentially every request. Cloudflare tolerates the burst most of the time and kills roughly one in ten to twenty.

Did we cause it?

No. The evidence:

• Zero dependency changes. Your 13 commits left package-lock.json untouched; package.json gained only an allowScripts install allowlist.
• The bundle barely moved. 2,139 KiB gzip at Phase 0 planning → 2,142.74 KiB now. The entire phone report writer cost +3.7 KiB, 0.17%.
• The failures are on / and /login — routes the phone work never touched. / is a 12-line redirect.

A 4 KiB delta cannot turn a 10 ms budget into a 190 ms cold start. The 8.2 MB bundle is upstream's architecture: React Router SSR, the full Hono API, Drizzle, the docx/xlsx export path, the MCP server, workflows and browser rendering all in one Worker.

Does origin address it?

No, and it's worse than silent. I searched the upstream repo — no issue mentions 1102, CPU limits, or Free-plan viability. Meanwhile the README says:

verified end-to-end on the Cloudflare Workers Free plan (2026-05-31)

And the only guard in the repo, scripts/check-bundle-size.mjs, watches the script size limit — "Workers Free: 3 MiB gzipped" — which you pass comfortably at 70%. Nothing in the repo watches CPU time. Upstream is measuring the one Free-plan limit this app doesn't hit, while blowing the one it does. That's worth an upstream issue once you're unblocked; it's a real finding about their deploy claim.

----------------------------------------------------------------- You posted my message verbatim, which means the caveat I attached didn't go with it. I told you:

I inferred Free plan from that 10 ms figure matching the documented limit exactly, not from your billing page. Confirm it on the Cloudflare dashboard before paying.

The post states Free plan as established fact. And there's a soft spot a sharp maintainer will find: the table shows 39 invocations at 11–191 ms returning ok. If the limit were a hard 10 ms per request, those should have failed too. My reading is that Cloudflare's Free enforcement isn't a strict per-request kill — it tolerates bursts, and startup CPU is reported in cpuTime without being charged the same way. That reasoning isn't in the post, so the strongest objection to it is sitting right there in its own evidence table.

The core finding holds regardless — outcome: exceededCpu with the exception "Worker exceeded CPU time limit" is not ambiguous, and it isn't caused by your commits. But if your dashboard says Paid, the post's central claim is wrong and you'd want to correct it yourself rather than be corrected.

That dashboard check is now doing double duty: it decides your $5 fix and whether your public post needs an edit. It's the one thing I can't do for you.

Also worth flagging since it's public: the post keeps the framing I wrote for you — "Did we cause it?", "your 13 commits", "worth an upstream issue once you're unblocked." Addressed to you it reads fine; addressed to the maintainer it reads like you're talking about them in the third person. Harmless, but you may want a follow-up comment that reframes it as a question to them.

[NCHILLC]

Follow-up — correcting my own diagnosis above.

I want to amend my conclusion before it misleads anyone. I attributed the failure to the Workers Free plan's 10 ms per-request CPU limit, on the strength of the failing invocation reporting cpuTime: 10. I now think that was coincidence, and my own evidence contradicts it.

In the same 45-request sample:

39 warm invocations reported 11–31 ms CPU and returned ok
5 cold starts reported 118, 149, 178, 180, 191 ms and returned ok
None of those could succeed under a hard 10 ms per-request cap. And the failure was:

outcome: exceededCpu
cpuTime: 10 wallTime: 13
exception: "Worker exceeded CPU time limit."
url: /login status: 503
13 ms of wall time cannot contain a per-request CPU breach on either plan. exceededCpu alongside an implausibly low cpuTime/wallTime is the known signature of the script startup limit — the isolate exceeding its budget evaluating global scope, with that cost not attributed to the handler that triggered it. That limit is the same on Free and Paid, so upgrading would not fix it.

What makes this plausible here is bundle size. From wrangler deploy --dry-run on my tree (13 commits ahead of upstream, but no dependency changes — package-lock.json untouched):

Total Upload: 8354.79 KiB / gzip: 2142.74 KiB
8.35 MB of JavaScript parsed and evaluated on every cold start.

The failure rate I measured was roughly 5% of requests across ~140 samples, and it is route-independent — including /, whose loader is a cookie read and a redirect. A route that does no work cannot exceed a per-request budget, but it can be the request that pays for a cold start.

scripts/check-bundle-size.mjs guards the 3 MiB compressed script size limit, and the bundle passes it comfortably at ~70%. Nothing measures startup cost, which looks like the actual binding constraint.

Four questions, and I'm happy to be told I've misread this:

Has 1102 been reported against a stock one-click deploy before?
Is the README's "verified end-to-end on the Workers Free plan (2026-05-31)" still current? I'd be curious what traffic shape that verification saw — the failure only appears on cold isolates, so a warm session wouldn't surface it.
Would you be open to a PR that defers the heaviest module-scope work off the request path? The docx/xlsx export, the MCP server, and browser rendering all currently evaluate before a login page can render.
Would it be worth having the bundle gate also assert on the Worker Startup Time that wrangler deploy reports, alongside the size check? Size is passing while startup is what fails.

(All of this above was written by Claude. I'm posting this as informational, only, with good intentions)

[NCHILLC]

Resolved — root cause found, and it's one import.

server/durable-objects/inspector-mcp.ts:7

import snapshot from '../lib/mcp/openapi-snapshot.json';

openapi-snapshot.json is 875,881 bytes (505 entries). A static JSON import becomes a JS object literal that V8 materialises during module evaluation — so this is paid on every cold start of the whole Worker.

It cannot be anywhere else, either. InspectorMcp has to be a static export for wrangler to bind the Durable Object class, and server/lib/mcp/oauth-provider.ts imports it as well, with buildOAuthHandler running on every fetch. So the snapshot sits in the eager module graph in front of every request — including requests that never touch MCP.

MCP_ENABLED does not save it. buildOAuthHandler returns { fetch: appFetch } unchanged when the flag is off — but only after this module has already been evaluated. A deployment with MCP switched off pays the full startup cost and gets nothing back for it.

This is also the invariant workers/app.ts states for itself, a few lines above the DO re-exports:

These MUST stay static (wrangler binds the classes at module scope); their import graphs must stay light

The fix

Both readers (registerGrantedTools, registerGrantedResources) are already async and only touch the snapshot at session-registration time, so it moves behind a cached dynamic import:

let snapshotPromise: Promise<SnapshotEntry[]> | undefined;
const getSnapshot = (): Promise<SnapshotEntry[]> =>
    (snapshotPromise ??= import('../lib/mcp/openapi-snapshot.json').then(
        (m) => m.default as SnapshotEntry[],
    ));

The class export stays static, so wrangler is unaffected; only the payload defers. It matches getComponentSchemas() ten lines below, which already defers the rest of the OpenAPI document for exactly this reason.

Effect on the bundle

Mapping static vs. dynamic reachability from the entry chunk:

  | before | after -- | -- | -- Eager graph (evaluated every cold start) | 1,291 KiB | 791 KiB — entry chunk | 1,258 KiB | 757 KiB Total upload | 8,355 KiB | 8,355 KiB

The 120–190 ms cold starts are simply absent now. Nothing above 20 ms.

One suggestion

scripts/check-bundle-size.mjs passes this build at 69.7% of the 3 MiB compressed limit, and passed it throughout — because compressed script size was never the binding constraint. Startup was, and nothing measures it.

wrangler deploy already prints Worker Startup Time. Asserting on that alongside the size check would catch this whole class of regression, and would have caught this one.

Happy to open a PR with the change and the gate if that's useful — it's a three-line diff plus a comment explaining why the import can't go back.

[important-new]

Thank you — this was a much better investigation than ours, and your self-correction in the second comment is exactly what we would have got wrong. The fix is now on main.

What we changed. inspector-mcp.ts now loads openapi-snapshot.json through a cached dynamic import. The entry chunk dropped from 1,303,025 → 769,776 bytes at that commit (770,508 on main today). We also confirmed that MCP_ENABLED cannot prevent eager module evaluation, and workers/app.ts explicitly requires those Durable Object import graphs to stay light.

One correction. We couldn't reproduce the CPU improvement: wrangler check startup was 61.4 ms before vs. 61.0–66.2 ms after across four runs. Our bundler emits the snapshot as JSON.parse(...), which may explain part of the difference.

We also tested two other eager-import reductions. They significantly improved cold startup (273 → 59 ms) but had essentially no effect on warm production traffic (10.48 → 10.86 ms/tick, ~290 invocations each side). So the important distinction seems to be cold-start cost vs. warm production CPU.

That doesn't contradict your finding. A ~900 KB eager payload is still worth removing, and your 1102 case is exactly where cold-start cost matters. If you're still seeing the 120–190 ms reduction, we'd be very interested — your tree is 13 commits ahead, so there may be a build difference worth finding.

On the gate: we now report wrangler check startup but hard-fail on entry-chunk bytes, since that is deterministic across CI machines.

On 1102/docs: we also corrected the README and related documentation. We had actually hit 1102 twice on our own hosted deployment, but for a different CPU-limit reason. A 24-hour sample since then shows 1 exceededCpu in 1,996 invocations. We also removed an outdated React Router SSR CPU claim after checking seven days of live traffic.

One important goal of OpenInspection is to build a product that can be deployed for free on Cloudflare and operate within the Cloudflare Free plan limits. Worker CPU execution time is currently one of the main constraints we're working through, and we've already made several changes in that area.

If you find other scenarios where we exceed the Free-plan limits, please let us know. PRs are very welcome as well.

And sorry I didn't catch the discussion earlier — I should have been paying closer attention.

Thanks for taking the time.