Cloudflare brings CPU and memory profiling to Workers in production

What changes in the Workers toolbox

Cloudflare announced on October 9, 2026, on-demand CPU and memory profiling for Workers and Durable Objects in production, according to reporting by InfoQ. The feature generates interactive flamegraphs through the Workers Observability dashboard or the cf CLI, making it possible to investigate bottlenecks without relying solely on logs and aggregated metrics.

In the flamegraph, wider sections indicate functions responsible for a larger share of CPU time or sampled memory allocations. Profiles can also be downloaded for offline analysis. For anyone who has already wasted time trying to reproduce locally a latency spike that only happens under real traffic, this is the most relevant practical change.

How profiling works on an already running isolate

The key difference is that profiling targets an isolate that's already running, not a new process started for the test. This makes it possible to examine code running under real production traffic, instead of simulating load in a development environment.

The engineering behind this has to deal with Cloudflare's distributed edge infrastructure, where the same script can have multiple isolates spread across different data centers and physical machines. A profiling request needs to identify the requested Worker version and locate a suitable active isolate to capture.

For CPU, the runtime starts a V8 profiler that samples call stacks at one-millisecond intervals. It releases the isolate's lock while requests keep being processed normally, and only reacquires it to stop profiling and collect the results. In practice, this means observing live execution without suspending request processing during capture.

There are two practical conditions for the feature to work well: the target needs to receive enough traffic during the capture window, and TypeScript devs should enable source maps so function names appear legibly in the flamegraph.

CPU and memory answer different questions

CPU profiling samples call stacks to reveal where execution time is being spent, helping identify expensive functions, redundant computation, and optimization opportunities. Memory profiling, on the other hand, highlights allocations associated with functions, helping find code that creates excessive objects or contributes to memory pressure.

A function can consume significant CPU without allocating much memory, while another can generate substantial allocations without dominating execution time. Examining the appropriate profile for each symptom helps narrow the investigation down to the right bottleneck, instead of guessing between two types of problems that look the same from the outside.

Durable Objects require specific routing

Durable Objects get additional support for profiling a specific named instance, useful when investigating problems tied to stateful workloads. The extra challenge is that these objects are stateful and can move between physical locations over time.

To solve this, Cloudflare routes the profiling request to the machine hosting the specific object at the moment of capture. It's an engineering detail that matters in practice: without this dynamic routing, profiling Durable Objects would be useless in any real distributed production scenario.

The internal case: where the numbers come from

Cloudflare itself used the feature internally to identify unnecessary computation and memory consumption before releasing it publicly. Two findings illustrate the type of problem profiling exposes:

• Profiling a Worker with an R2 binding revealed a recursive JSON replacer that repeatedly traversed nested data, doing redundant work; fixing the implementation made the function, according to Cloudflare, 2.7 times faster.
• Another profile exposed a duplicate, unnecessary metrics call, responsible for about 1% of CPU time.

On the memory side, profiling identified partially disabled Prometheus instrumentation that was still consuming substantial memory. Cloudflare states that removing the remaining code reduced the Worker's p99.9 memory usage from 133 MB to 118 MB, bringing it below the platform's 128 MB limit.

How it compares to Chrome DevTools and pprof

The feature complements already established tools rather than replacing them. Chrome DevTools offers local CPU profiling, useful during development, but reproducing production traffic and data locally tends to be difficult or impossible. pprof, widely used in Go and other supported profiling workflows, offers powerful offline profile analysis, and Cloudflare itself allows examining downloaded profiles with pprof.

Cloudflare's differentiator is the ability to start profiling against Workers and Durable Objects that are already running, through the operational interface the platform already offers. Combined with logs, metrics, and distributed tracing, profiling helps pinpoint exactly which function is responsible for behavior that these other tools have already flagged as slow or costly.

What's still open

On-demand capture isn't continuous monitoring. Short profiling windows may not catch intermittent problems, and heap profiles record allocations only during capture, without giving a complete picture of memory retained over time. Cloudflare says it's working on continuous profiling, which could make it easier to investigate rare problems without needing to anticipate when they will happen.

For those running Workers in Brazil

For Brazilian teams already using Cloudflare Workers in production, especially in edge-first scenarios with latency critical for users in the country, the practical change is moving away from the "add more logs and hope" mode to isolating the function responsible for a bottleneck without reproducing the scenario locally. This matters especially in architectures with stateful Durable Objects, where reproducing a production bug outside the real environment tends to be nearly impossible.

It's worth testing the flow first on a low-risk Worker, capturing a CPU profile via the cf CLI during a real traffic spike, before relying on the tool to diagnose an incident under pressure. And for those who already use pprof in a Go stack, export compatibility reduces the friction of incorporating Cloudflare's profiling into the observability flow that already exists.