Cloudflare adds CPU and memory profiling for Workers in production

Cloudflare has added on-demand CPU and memory profiling for Workers and Durable Objects in production. The announcement, published on the official blog on 9 October 2026, is aimed at anyone who has encountered error 1102 ("Worker exceeded resource limits") and has previously had to guess the cause by examining logs and aggregate metrics.

How it works in practice

Today we announce support for CPU and memory profiling of Workers and Durable Objects. From the Workers Observability page you can now request an on-demand CPU or memory profile of an active Worker, inspect it as an interactive flamegraph and download the profile file for further analysis. The interesting technical detail is that profiling happens on an isolate already in execution, with real traffic: the Workers runtime holds the isolate lock only briefly during profiler start/stop operations, not for the entire duration. It acquires the lock to start a V8 CPU profiler that samples at one-millisecond intervals, releases it so requests continue to be processed, waits for the requested duration, then reacquires the lock only to stop profiling and serialise the results.

How to enable it

From dashboard: navigate to the Workers page in your account, select the Worker, open the Observability tab and use the dropdown menu to choose "Flamegraph". From the command line, the command is:

cf workers versions profile latest \
 --worker-id "$WORKER_ID_OR_NAME" \
 --duration-ms 5000 \
 --profile-type cpu > worker-cpu.pprof

One detail worth noting: the Worker needs sufficient traffic to be profiled successfully, so it's worth choosing a version that receives enough traffic. If the code is in TypeScript, Cloudflare recommends enabling source maps, otherwise the flamegraph will show obfuscated function names.

The internal case: from 133 MB to 118 MB

Cloudflare used the tool on its own Worker that handles R2 binding. By profiling CPU, it found a recursive JSON replace function that repeatedly traversed nested data, performing redundant work; correcting the implementation made it, according to Cloudflare, 2.7 times faster. On the memory front, another internal Worker had a more insidious problem: memory at the P999 percentile was hovering around 133 MB against the 128 MB limit per Worker, causing frequent eviction with an "Exceeded Memory" error. The heap profile revealed that the Prometheus code accounted for approximately 66.7% of allocations in the profile, code that should have been disabled but was still partially running. Once that code was removed, the P999 memory dropped from 133 to 118 MB.

Why it matters for those running these servers

Profiling doesn't change the limits, it just helps you stay within them. On the Free plan, the cap remains 10 ms of CPU per HTTP request and cannot be raised; on Paid, the default is 30 seconds, configurable up to 300,000 ms (5 minutes) via limits.cpu_ms in wrangler. Memory remains fixed at 128 MB per isolate on both plans. Anyone managing Workers in production with recurring exceededCpu or exceededMemory errors in logs can now capture a real profile instead of modifying code by trial and error.

Prime Server, Koapanel, KoaVM and Koabilling are not involved in this announcement: this is a native feature of the Cloudflare Workers platform.