CI was green. The deploy was failing.

Context

A multi-tenant SaaS backend running on Cloudflare Workers, deployed through a pipeline that had been reliable for months.

The problem

Deploys were silently failing. The worker had crossed the Cloudflare startup CPU limit — error 10021 — which is enforced during module evaluation, before a single request is served. The build succeeded, the pipeline went green, and the code never reached production.

Why it was difficult

Every signal the team had was reporting success. The failure happened in the deployment path rather than the build, so the usual place to look was clean. A limit measured in milliseconds of startup evaluation also has no obvious relationship to any line of application code, which makes it hard to bisect: nothing anyone wrote was slow, and the total had grown past the ceiling anyway.

Diagnosis

I profiled the dependency graph and the top-level evaluation cost separately, because they are different problems that present identically. Bundle size turned out to be a symptom rather than the cause — the cause was how much work happened at module load, and how much of the graph was being pulled in to support it.

What changed

• Replaced a broad googleapis import with scoped @googleapis/* packages — the single largest contributor to the graph
• Moved DocuSign behind a lazy import so it costs nothing until it is used
• Removed a seed-only faker dependency that had no business in the runtime graph at all
• Deferred and memoized expensive OpenAPI and YAML work that was running on every cold start

Technical notes

• The startup CPU limit is evaluated at deploy time, not request time, so it fails in a place most pipelines do not check.
• Bundle size is not a reliable proxy for startup cost. The two were reduced by different changes, and profiling top-level evaluation was what actually moved the second number.
• Memoizing the OpenAPI work meant the cost moved from every cold start to the first request that needs it.

Business impact

The immediate result was that the backend could ship again. The more durable one is that the team can now tell a bundle-size problem from a startup-evaluation problem before it blocks a deploy, because the two were measured separately and the difference was written down.

What this demonstrates

Production debugging rather than bundle optimization. The reduction figures are the visible part; the useful part was noticing that a healthy pipeline was reporting on something other than what was actually shipping.