Key details

  1. Announced October 9, 2026 for Workers and Durable Objects.
  2. CPU and allocation profiles are available through dashboard, cf CLI and API.
  3. Can target a named Durable Object and a selected active Worker version.
  4. Capture duration 1–50 seconds; active traffic is required.
  5. Heap profiling samples allocations rather than retained memory.
  6. Source maps improve readability for TypeScript; raw profiles are pprof-compatible.
  7. Continuous profiling is planned but not yet delivered.

What builders should take away

  1. Use production profiles when local DevTools cannot reproduce CPU or memory failures.
  2. Drive representative traffic during a capture and ensure the target isolate is loaded.
  3. Enable source maps and inspect pprof exports when the dashboard flamegraph is insufficient.
  4. Avoid interpreting allocation profiles as proof of live memory retention or complete startup behavior.
  5. Use tracing and profiling for different questions: request flow versus function-level resource consumption.

What changed

On October 9, 2026 Cloudflare introduced on-demand CPU and heap-allocation profiling for deployed Workers and Durable Objects. Developers can request a capture through the dashboard, Cloudflare CLI or API, view interactive flamegraphs, and download pprof-compatible output. Captures target live loaded isolates and can select a specific named Durable Object. Official documentation permits capture windows of 1–50 seconds. Previously, profiling was limited to local DevTools sessions that could not reproduce production traffic conditions.

Why it matters

A deployed Worker can hit CPU or 128MB memory limits because of workload patterns invisible to local tests. Function-level profiling lets teams identify actual hot paths and allocation sources rather than guessing from aggregate usage metrics. Cloudflare's internal examples report a 2.7x improvement in one wasteful JSON function and a memory fix that lowered p999 usage from 133MB to 118MB, but these are vendor examples rather than universal performance gains. The feature is distinct from Cloudflare Traces, which follows request paths across services.

Profiling targets running production code

Developers select a Worker version or named Durable Object, request CPU or heap allocation profiling and inspect the resulting flamegraph. The CLI and API return pprof-compatible data for external analysis. Capturing does not start a new isolate, so the target must be actively receiving traffic.

Heap profiles measure allocations, not retained memory

Cloudflare samples allocation stack traces every 512KB allocated during the capture. It is not a heap snapshot and cannot determine which objects remain live. Startup allocations or rare failures outside the requested window will not appear.

Short capture windows and rate limits shape use

Documentation allows 1,000–50,000ms captures. The API rate-limits profiling requests with HTTP 429 and Retry-After; low-traffic Workers may have no loaded isolate to profile. Source maps should be enabled for readable TypeScript function names.

Cloudflare's own fixes demonstrate the debugging boundary

Cloudflare says its R2 binding team found redundant recursive JSON traversal and optimized that function by 2.7x. Another team used heap allocation profiles to remove disabled-but-still-running Prometheus instrumentation, reducing p999 memory from 133MB to 118MB. These are internal cases, not independent benchmarks.

What to watch next

  • Continuous profiling availability and pricing.
  • Profiling reliability for short-lived and low-traffic isolates.
  • How sampling and rate limits work at scale and across paid plans.

Still unclear

  • Cloudflare has not announced general continuous profiling or comprehensive pricing details for future profiling tiers.
  • Vendor performance examples may not generalize to customer workloads.
  • Allocation sampling can miss allocations outside the selected window.

Sources

Direct reading behind this dossier.

3 sources
Profiling in production
Cloudflare Developers primary documentation

Capture limits, CLI, API, heap semantics and error conditions.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment