Cloudflare Workers can now be profiled in production, CPU and memory, on demand
Serguey Asael Shinder2 min readCloudflare announced on 9 October that Workers and Durable Objects can be profiled in production on demand: from a Worker's Observability tab, or through the API and the cf CLI, you request a CPU or memory profile of a live version, watch it render as an interactive flamegraph (or a sortable table), and download the profile file for other tools. Until now Workers could only be profiled locally through Chrome DevTools, which never sees production traffic.
How it samples without stopping your code. The runtime takes the isolate lock only to start and stop the profiler. For a CPU profile it creates a V8 CPU profiler sampling every millisecond, releases the lock so requests keep running, waits out the requested duration, reacquires the lock to stop, and serialises the result outside the critical section. Holding the lock for the whole window would freeze the very code being measured.
The constraint to plan around: it observes, it does not start anything. No fresh isolate is spun up for a profile, because the goal is real production execution. A Worker version with little traffic may therefore be hard or impossible to profile; Cloudflare says to pick a deployed version that receives plenty of requests. Ordinary Workers are stateless, so the system picks one running isolate of the requested version at random. Durable Objects are the exception that makes this useful for debugging state: you name the object, and the request is routed to the machine holding that specific actor.
Two examples from Cloudflare's own services. In the Worker behind the R2 binding, a JSON replacer called by JSON.stringify also walked the tree itself, so deeply nested values were processed repeatedly; it took over 5% of CPU time, and the fix made that function 2.7× faster. A duplicate metrics call cost about 1% on its own. In another Worker, P999 memory sat around 133 MB against the 128 MB limit, causing evictions with Exceeded Memory errors; a heap profile showed instrumentation code believed to be switched off accounting for about two thirds of allocations. Removing it left roughly 10 MB of headroom.
Limitations Cloudflare lists itself: a session has to be started by hand, so you can miss the moment a Worker misbehaves; and the memory profiler only shows allocations made during the window, so start-up allocations are invisible. The company says it is working on continuous profiling to cover rare events. For TypeScript projects, source maps need to be enabled or the flamegraph shows mangled function names.
Source: Cloudflare Blog, Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects, 9 October 2026 — https://blog.cloudflare.com/workers-on-demand-profiling/