Continuous Profiler

Traces are the path, profiles are the distribution

An APMtrace records which processing in which service a single request passed through and how many milliseconds each span took. A profile, by contrast, is an aggregation of the CPU time and memory allocation a process used over a given period, broken down by the function that was executing. The official documentation explains that Datadog's Continuous Profiler shows CPU / memory / I/O bottlenecks broken down to method name / class name / line number (as of September 2026; source: Continuous Profiler). A trace answers "why was this one request slow," and a profile answers "what is this service spending its time and memory on." The two do not compete; they solve different questions.

Profile types are not just CPU

It is easy to assume "profiler = CPU usage," but the types that can be collected are several per language. For Java, the official documentation lists 10 types: CPU / Wall Time / Allocations / Allocated Memory / Live Heap / Class Load / Thrown Exceptions / File I/O / Lock / Socket I/O (as of September 2026; source: Profile Types). CPU shows "the time a function ran on the CPU," Wall Time shows "elapsed time including waits on I/O," and Live Heap shows "the functions that allocated objects not yet collected," which is effective for memory leak investigations. Because this distinction exists, you can make the first-move triage that a service which is slow even though its CPU profile is flat has its cause on the Wall Time or Lock side. The lineup of types differs by language, so check the page for your own language.

Which languages it supports and what it requires

The enabling page lists 10 languages: Go / Java / Node.js / PHP / Python / Ruby / .NET / Rust / C / C++, and for Java there is also a variant for GraalVM native images (Preview) (as of September 2026; source: Enabling the Profiler). On the JVM side, Scala / Groovy / Kotlin / Clojure are also covered, and for Java on Windows the available types are narrowed to 4. The prerequisites are the Datadog Agent on the host (v7 or later recommended) and the same SDK as APM. Because it is bundled in the SDK, a Java service that already has APM needs no additional library. The caution is serverless: the Java page states explicitly "not supported on serverless platforms," and for some languages the AWS Lambda variant is at the Preview stage (same point in time; same source).

The Profiles tab: from a slow trace to the relevant line

In a process where both distributed tracing and the profiler are enabled, the two kinds of data are linked automatically, and from the Profiles tab on a slow span's screen you can move directly to the profile of the code that was running while that span executed (as of September 2026; source: Investigate Slow Traces or Endpoints). The Profiles tab has a timeline view that breaks the span's duration down by thread, and the flow is to switch to the flame graph with "Open in Profiling" and look for wide functions. The order of investigation becomes a single path: "identify the slow endpoint → open the span → look at the relevant line of code." As a prerequisite, for Java this linkage is enabled by default on Linux and macOS and is not available on Windows. In manually instrumented code, wrapping the span in an active scope is the condition for the linkage (same point in time; same source).

Showing "which function is consuming" per endpoint

The flame graph for a whole service mixes the processing of multiple endpoints. Endpoint profiling is a feature that narrows the flame graph to any endpoint you choose, and it can be used to identify the methods dragging down response time, to extract the endpoints that consume the most CPU / memory / exceptions, and to tell whether the cause lies in your own code or in a third-party library (as of September 2026; source: Investigate Slow Traces or Endpoints). "Per endpoint call" lets you view the consumption per request. Whether total CPU rose because traffic increased or because a single request became heavier calls for opposite remedies, and this toggle makes the distinction. In the Profiling tab of the APM service page, you can see changes in latency side by side with changes in code performance. Without it, the search for a cause becomes a comparison of diffs; with it, you can go straight to the name of the line that got slower.

Does running it all the time weigh down production?

The official documentation explains that it is designed to run in production across all services, keeping the impact on host CPU and memory to a minimum through technologies such as JDK Flight Recorder (as of September 2026; source: Continuous Profiler). No percentage figure is given. The Go defaults disable the higher-overhead types (Block / Mutex) (source: Enabling the Profiler), and there is a note that while a Go execution trace is being recorded, a CPU increase on the order of garbage collection can occur (same point in time; source: Investigate Slow Traces or Endpoints). As for retention, flame graphs / call graphs / thread timelines are kept for 8 days by default, metrics derived from profiles are kept for 1 month, and a flame graph exported to a notebook stays for 1 year. 8 days lets you compare before and after a deployment, and 1 month of metrics lets you follow the trend of the top CPU methods.

Pricing takes 3 forms - per-host price, per-container price, and bundled in Enterprise

Billing is based on the number of hosts sending profiles. Pricing takes three forms. First, the per-host unit price of Continuous Profiler on its own, where the annual commitment is the lowest and monthly commitment and on-demand share the same unit price. Second, a per-container unit price for containers beyond the allotment included in the host license, billed per container per month for annual and monthly commitments and in fine per-container-per-hour increments for on-demand. Third, the per-host unit price of APM Enterprise, which bundles Continuous Profiler with APM Pro (SKU breakdown as of August 2026; source: Datadog Pricing). For the actual unit prices, check the same page.

If you intend to use both, choose by comparing, on the pricing page, the sum of the APM host unit price plus the standalone Continuous Profiler host unit price against the APM Enterprise host unit price. The overall picture of the three-tier host unit prices and allotments is left to our explanation of APM pricing. For the structure in which per-host prices stack up, see how to read the pricing structure.

When to add it - after APM has narrowed the target

The profiler is not the kind of tool you install on every host from the start. The sequence that makes sense in both cost and effect is: after APM has narrowed down "which endpoint of which service is slow," install it on that service and descend to the granularity of functions. Thinking in the following three steps removes the hesitation.

The tier to keep always on is the one where "function-level improvements translate directly into money," such as high-traffic services where the number of CPU hosts is the cost itself, or JVM services where lock waits are suspected. There, you check whether the profiler's per-host unit price can be recovered through the infrastructure cost of the hosts you manage to cut. Conversely, for batch jobs and small internal services, enabling it only for the period when a performance problem appears is enough. The fact that the on-demand unit price for containers is set by the hour is a design that suits this short-term use well. Without it, the discussion stalls at "the cause of the slowness is somewhere in the code"; with it, that discussion ends with a line number. That is the conversation this product changes.