Cloudflare has announced on-demand CPU and memory profiling for Workers and Durable Objects. The tool lets developers observe code running in production, view the results in a flamegraph, and download files for further analysis.
What matters here is more than another monitoring screen. When an application slows down or runs out of memory, logs and aggregate metrics often reveal the symptoms without identifying which function is causing the problem. Profiling adds a code-level view, helping operations teams narrow down resource-intensive work.
From aggregate metrics to individual application functions
According to Cloudflare’s announcement of profiling for Workers and Durable Objects, users can request CPU or memory profiles from the Workers Observability page, selecting a Worker version and recording duration. Results appear as an interactive flamegraph and can also be downloaded for use in other analysis tools.
In this graph, each rectangle represents a function call. Its width indicates the CPU or memory used by that function in the profile. Users can click to focus on a branch of function calls or switch to a table view to find functions that appear frequently in the collected samples.
The difference from local testing lies in the real-world workload. Cloudflare says Workers already supports local profiling through Chrome DevTools, but data from a development machine does not fully reflect the types of requests and traffic an application receives in production.
A small piece of processing may go unnoticed during testing but become a major cost when called repeatedly. This is also why profiles need to be interpreted in the context of traffic, rather than treating one graph as a conclusion that applies to every situation.
Two examples show how unnecessary work can remain hidden
Cloudflare gives an example from a Worker implementing a binding for the R2 storage service. In the CPU profile, the team found that a replacer function used when converting data to JSON accounted for more than 5% of CPU time.
The problem was that this function traversed the data tree itself, while JSON.stringify also called it at each node. According to the company’s description, a value nested five levels deep was processed five times. Removing the duplicate work made that function alone 2.7 times faster. This does not mean the entire application became faster by the same factor.
Another case involved memory. Cloudflare says an internal team found that Prometheus code accounted for about 66.7% of allocations in the profile of a Worker experiencing memory-limit errors. The team had previously believed this code was disabled, but it was still collecting data across multiple execution paths.
After that code path was completely removed, memory usage at the P999 percentile fell from 133 MB to 118 MB, according to figures published by Cloudflare. The example shows that a configuration understood to be “turned off” does not necessarily eliminate processing costs. However, this is a result from an internal system, not an improvement guaranteed for every Worker.
Enough traffic and readable function names are needed
To collect a profile from the dashboard, developers go to the Workers list, select the application, open the Observability tab, and then select Flamegraph. Cloudflare also provides a command-line option through the cf package.
Two conditions directly affect the value of the results. First, the selected Worker version needs enough traffic for profiling to succeed. A version receiving almost no requests may not produce a useful profile.
Second, for TypeScript projects, Cloudflare recommends enabling source maps. Without information mapping back to the source code, profiles may display transformed function names, making it harder to connect a bottleneck to the code that needs changing.
The company also recommends collecting several profiles rather than looking just once. From an analytical perspective, this helps distinguish a temporarily prominent pattern from work that regularly consumes resources. A memory profile highlights notable allocation sites, but on its own it is not enough to establish that an application has a memory leak.
What this means for applications already in production
The new tool adds a layer of observability for teams building websites, APIs, or internal applications on Workers. Instead of making guesses based on an “Exceeded Memory” error or rising CPU usage, development teams have more data to help decide which code to examine first.
This is the next step after building an application: code that runs is not necessarily code that operates reliably. For internal tools built quickly, resource observability complements the data and access requirements discussed in the article on employees building their own AI applications and the governance challenge.
This announcement also sheds light on part of Cloudflare’s direction in expanding its developer tools, alongside the updates compiled in the October 9 application infrastructure news roundup and the October 10 technology news roundup.
The published examples show that profiling can uncover repeated work and costs from code thought to be inactive. The improvement for each application still depends on its execution paths, real-world workload, and the changes implemented after analysis; the tool provides evidence for investigation rather than fixing bottlenecks itself.
Frequently asked questions
Does a wide rectangle in a flamegraph always indicate a bug?
No. A function may use substantial resources because it is doing necessary work, such as processing data. Width helps identify where to investigate first; the code and business requirements must be examined to determine whether optimization is possible.
Can the 2.7-fold speedup be used to predict results for other applications?
No. This is the result Cloudflare reported for a specific function after removing duplicate processing. The impact on the entire application depends on that function’s share of the workload and the remaining work.