Cloudflare Adds CPU and Memory Profiling for Workers and Durable Objects

Cloudflare has introduced CPU and memory profiling for Workers and Durable Objects in production. Developers can explore interactive flamegraphs to find functions consuming resources.

· 5 min read · 5 comments

On October 9, 2026, Cloudflare introduced CPU and memory profiling for Workers and Durable Objects running in production. According to The Cloudflare Blog, developers can request a profile of an active Worker, explore the results in an interactive flamegraph, and download the file for further analysis. This helps identify functions that consume CPU time or allocate memory when aggregate metrics and logs aren’t enough.

How to Profile Running Code

Profiling can be started from the Observability tab in the Cloudflare dashboard or through the CLI. In the dashboard, you select a Worker, a profile type—CPU or memory—and how long to collect data. You can also specify the Worker version. Once the recording is complete, a flamegraph appears: each rectangle represents a function call. Its width reflects the CPU time or memory attributed to that function. You can click a function to inspect it more closely. A table helps identify the functions that appear most often in the profile.

The point of profiling in production is to see code under real load. Local profiling with Chrome DevTools was already available, but the mix and volume of requests there may differ from production. The new tool doesn’t spin up a separate Worker instance to record a profile: it looks for one that’s already running. To collect a profile successfully, you therefore need to choose a deployed version with enough traffic. Profiling a Worker that receives few requests may be difficult.

For Durable Objects, you can select a specific object by name. Unlike regular Workers, these objects maintain state and can move, so the profiling request is routed to the server running the relevant instance. Recording a CPU profile doesn’t pause Worker execution for the entire observation period: the runtime releases the lock between the start and end of data collection so normal requests can continue to run.

If a Worker is written in TypeScript, Cloudflare recommends enabling source maps. Otherwise, the profile may contain function names that are hard to recognize. The graph will still be available, but matching those functions to the relevant parts of the source code will be more difficult.

What Cloudflare Found in Its Internal Tests

The team recorded a 50-second CPU profile of a Worker that handles an R2 binding. The genericR2JsonReplacer function stood out in the table, accounting for more than 5% of CPU time. The profile revealed that nested values were being processed twice: JSON.stringify called the function, which then traversed the tree again. Removing the redundant work made the function 2.7 times faster.

The same profile helped uncover a repeated call to metrics. One call accounted for 1% of CPU time; caching the result of the first call avoided running the expensive operation a second time. These were small code changes that became easier to justify once the team could see resource use by function.

In another Worker, memory allocations were the problem. P999 reached 133 MB against a 128 MB limit, causing the Worker to frequently terminate with an out-of-memory error. The profile showed that roughly 66.7% of allocations came from Prometheus code. The team thought it had been disabled, but some of it was still running. After removing that section entirely, P999 fell to 118 MB, while P50 dropped from 70 MB to 54 MB.

What This Means for Projects Built on Workers

For developers, the main change is the ability to move from asking “why has resource use gone up?” to examining specific calls in running code. That’s useful when a problem only appears under real traffic or affects a particular Durable Object. You can inspect the profile in the dashboard or download it for separate analysis.

Site owners and marketers don’t need to read a flamegraph to understand the benefit: the team gets more concrete data to work with when improving server-side performance. But the results don’t appear automatically. Profiling has to be started manually, and a memory profile covers only allocations made during the selected period. If the problem happened earlier, or memory was allocated heavily when the Worker started, that recording won’t show it.

Cloudflare is already working on continuous profiling: the plan is to collect samples automatically and make them available for inspection in the dashboard. The announcement gives no launch date. For now, rare problems may be missed if recording doesn’t start at the right moment.

My Take: Measure First, Then Make Changes

I like that the tool shows function-level resource use under production load. In Cloudflare’s examples, the problem wasn’t the choice of tech stack. It was a repeated traversal of data, an unnecessary call, and code that hadn’t been fully disabled. A profile like this helps the team discuss a specific fix instead of guessing.

That said, I wouldn’t treat a single flamegraph as a ready-made product decision. It shows where resources are being spent during the selected period, but the team still has to decide what to fix first and how to verify the result. The recording window is an especially important limitation to keep in mind.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

  1. Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects blog.cloudflare.com

About the author

Bruno Mateo

Senior full-stack developer

I help teams speed up interfaces and server processes without chasing the next stack. If needed, I can explain a technical solution without assuming the other person already knows everything.

All posts by the author

Discussion 5

Leave a comment

Not published. We’ll send a link to confirm your comment.

No links or ads. Your first comment is published after review. By sending a comment you agree to the privacy notice.

  1. Ulyana Babayan

    I’ve run into a similar “the page feels slow, but the logs look fine” problem while building small web projects. On mobile, even a few extra steps or a heavy interaction can make the experience feel sluggish, so being able to inspect a specific Worker version and see which function is taking the time would make debugging much less guessy. I’d start with a short CPU profile, then check memory if the issue still isn’t clear.

    1. Klára Novotná

      @ube.am, one small distinction: the flamegraph points to resource-heavy functions, but it won’t tell you whether the extra steps or interaction are what users find slow; I’d pair the profile with a quick prototype check.

    2. Artūrs Rudzītis

      @ube.am, I’m not sure a CPU profile is the right first step just because the page feels sluggish. A Worker flamegraph can show where server-side CPU time goes, but it won’t tell you whether the delay is in the browser, network, or an interaction that simply adds steps. I’d first pin down a before-and-after metric for the affected path, then profile the specific Worker version if the evidence points to server execution; otherwise it risks optimizing the wrong layer.

      1. Niels Zander

        @arta_rudzite good point about separating browser, network, and Worker time first. The version-specific profile is useful once the before-and-after metric points to server execution; otherwise that flamegraph could send us optimizing the wrong layer.

        1. Paweł Kowalski

          I’d push back a little on waiting for a metric to clearly point to Worker execution before profiling. A short profile of the affected Worker version is relatively targeted evidence, and it can help rule server-side CPU in or out alongside browser and network timings. I’d still avoid treating the flamegraph as a diagnosis of the whole page, but it doesn’t have to be the last step after we’ve already isolated the layer.