The hardest part of debugging a Worker in production is that logs and aggregate metrics tell you that something is slow or heavy, not where. On October 9, 2026, Cloudflare announced on-demand CPU and memory profiling with interactive flamegraphs for Workers and Durable Objects, available from the Workers Observability tab in the dashboard or via the CLI. You request a profile of a live Worker, watch it render as a flamegraph, and download the raw profile for deeper analysis.
Why production profiling matters
Local profiling through Chrome DevTools has existed for a while, but a locally running Worker never sees the request volume or variety of the real thing. Cloudflare argues the best way to understand your application is to profile it in production, and their own internal examples back that up.
Two cases from the announcement are worth stealing for your own debugging playbook:
- A CPU profile of the Worker behind the R2 binding revealed
genericR2JsonReplacereating over 5% of CPU time because it walked the JSON tree itself even thoughJSON.stringifywas already visiting every node. Fixing the duplicated walk made the function 2.7x faster. A second profile showed ametricscall costing about 1% of CPU per invocation — caching the result fixed it. - An internal Worker kept getting evicted with “Exceeded Memory” errors, with P999 memory at 133 MB against the 128 MB limit. A heap profile opened in pprof showed their Prometheus instrumentation accounted for roughly 66.7% of allocations — code everyone believed was disabled. Removing it dropped P999 to 118 MB, buying about 10 MB of headroom.
That second example is the one I’d keep in mind: metrics told the team memory was the problem, but only the profiler pointed at the culprit nobody suspected.
How to run your first profile
The dashboard path: Build → Compute → Workers & Pages, pick your Worker, open the Observability tab, and choose “Flamegraph” from the dropdown. Set a duration, pick a version, and hit Capture Profile. Each rectangle is a function call; width is CPU time or memory. Don’t overthink the first capture — grab a couple of profiles, look for the widest functions, and use the table view to spot frequently sampled ones quickly.
Two practical gotchas from the docs worth flagging:
- Traffic matters. The profiler attaches to an existing running isolate rather than starting a new one, so a low-traffic version is hard to profile. Pick a deployed version that gets real requests.
- Enable source maps if your Worker is TypeScript, or you’ll be reading obfuscated function names.
Durable Objects get name-based targeting
Stateless Workers are replicated across data centers and even multiple physical servers, so the runtime has to answer a small set of routing questions before profiling: which version, which data center, is the isolate still loaded, does it belong exclusively to your account. For Durable Objects it’s simpler in a satisfying way — objects are stateful and named, so you can request a profile of a specific object by name and the runtime routes the request to whichever metal owns that actor.
Under the hood, the runtime holds the isolate lock only for lifecycle operations: start the V8 CPU profiler at a one-millisecond sampling interval, release the lock so requests keep flowing, then reacquire and stop after the requested duration. The Worker keeps serving while samples are collected.
What it doesn’t do yet
Profiling is explicitly on-demand right now, which means you can miss the window where your Worker misbehaves. And the memory profiler only shows allocations made during the profiling window — startup allocations are invisible. Cloudflare says continuous profiling, where samples are captured automatically and explored in the dashboard, is already in progress; that will matter much more for catching rare events.
For now, the practical move is to bake profile captures into your incident follow-ups rather than waiting for a crisis. If you’re treating Workers as your agent runtime — the way teams shipping agent infrastructure on Cloudflare do (as I covered earlier) — being able to point at the exact function burning CPU or heap is the difference between a hunch and a fix.