Cloudflare Adds On-Demand CPU and Memory Profiling for Workers and Durable Objects

On-Demand Profiling for Workers and Durable Objects

Cloudflare has announced support for on-demand CPU and memory profiling of Workers and Durable Objects. From the Workers Observability page, developers can request a CPU or memory profile of an active Worker, inspect it as an interactive flamegraph, and download the profile file for further analysis. The company says profiling in production is the best way to understand how an application behaves under real-world conditions.

How to Capture a Profile

Developers can start a profiling session through the Cloudflare Dashboard or the CLI. In the dashboard, navigate to Build, then Compute, then Workers and Pages, select a Worker, and open its Observability tab, where a Flamegraph dropdown lets you request CPU and memory profiles, set the duration, and pick a Worker version. The CLI option requires the cf package and a command such as cf workers versions profile latest with a worker ID, a duration in milliseconds, and a profile type, saving the output as a pprof file.

A Worker needs plenty of traffic to be profiled successfully, so developers should choose a version that is actively receiving requests. In the flamegraph, each rectangle represents a function call and its width shows how much CPU time or memory that function uses. Clicking focuses on a function, hovering shows details, and a table view helps identify the most common functions. TypeScript projects should enable source maps, otherwise function names may appear obfuscated.

Real-World Results

Cloudflare teams have already used the feature to optimize memory and CPU usage, fix out-of-memory errors, and improve performance. In one example, a CPU profile of the Worker implementing the R2 binding showed genericR2JsonReplacer accounted for over 5% of CPU time because it walked the JSON tree recursively on top of JSON.stringify, processing deeply nested values multiple times. Fixing the duplicate work made the function 2.7x faster. A duplicate metrics call, worth about 1% of CPU time, was also eliminated by storing the result in a variable.

Internally, a Worker was hitting the 128 MB memory limit, with P999 memory around 133 MB and frequent "Exceeded Memory" evictions. A heap profile taken in production and opened with pprof showed Prometheus code accounted for roughly 66.7% of allocations, even though it was supposed to be disabled. Removing that code path dropped P50 from 70 to 54 MB, P90 from 94 to 79 MB, P99 from 113 to 97 MB, and P999 from 133 to 118 MB.

How It Works and What Is Next

Profiling targets real production execution, so no new isolate is started for a profile. The runtime must first determine which version to profile, where it has run recently, whether its isolate is still loaded, and whether it belongs to the requesting account. For Durable Objects, which are stateful and named, the request can target a specific object by name and is routed to the metal owning that actor.

To avoid blocking traffic, the Workers Runtime holds the isolate lock only for profiler lifecycle operations. For a CPU profile, it creates a V8 CPU profiler sampling at one millisecond intervals, releases the lock so requests continue, waits for the requested duration, then reacquires the lock to stop and serialize the result.

Cloudflare notes limitations: sessions must be started explicitly, so short-lived problems can be missed, and the memory profiler only shows allocations during the profiling window, missing heavy start-up allocation. The company is working on continuous profiling that captures samples automatically so developers can explore profiles in the dashboard without starting sessions manually.

Sources: The Cloudflare Blog