Find slow Cloudflare Worker startup code from Wrangler
Wrangler 4.116.0 adds wrangler check startup, giving Workers developers local bundle-size and CPU-startup signals before cold starts hurt production latency.
What you get from it
Cloudflare added a practical diagnostic command for Workers teams that need to shrink cold-start cost before deploying a heavier bundle.
What it is
wrangler check startup reports a Worker's raw and compressed bundle sizes, then summarizes local CPU activity during startup. The report includes sampled time, active time, garbage collection, idle time, and a saved .cpuprofile file for deeper inspection in Chrome DevTools or VS Code.
Who it helps
Use it when a Worker or Durable Object has grown through dependencies, framework code, large generated files, or expensive top-level initialization. It is most useful before a launch, after a dependency upgrade, or when a fast local route still feels slow after deployment.
How to evaluate it
Update to Wrangler 4.116.0 or later, run the startup check locally, then inspect the .cpuprofile if the summary points to heavy startup work. Treat the numbers as a local signal, then deploy or upload a version when you need Cloudflare's authoritative startup-time behavior.
Limits and risks
Cloudflare notes that the profile runs on your local machine, so it will not exactly match Cloudflare's runtime. The command is a diagnostic tool, not a production latency guarantee. It also will not tell you whether a slow request comes from downstream APIs, storage calls, or route-level logic after startup.
Sources
Discussion
Share practical experience, questions, or warnings with the community.
Sign in to join the discussion and vote on comments.
Sign in