Trace

Overview

Datadog's official documentation describes a trace as something used to track the time an application spent processing a request and the status of that request. A trace is made up of one or more spans, and the spans are linked to each other in parent-child relationships. In a setup where a single request travels through multiple services, passing identifiers between services stitches the separately recorded spans together into one trace. What sets it apart from monitoring that looks only at aggregated numbers is that, beyond measuring how fast individual operations are, you can follow which interval consumed the time on a per-request basis.

A trace is the collected path of a single request

The role of a trace is to keep the processing time of a request and its status on a per-request basis. Its contents are one or more spans, and since each span carries the identifier of its parent span, the whole takes a branching shape rooted at the entry span. The entry span is treated as the origin of that trace.

The advantage of this shape is that you can talk about the cause of slowness in terms of differences. The fact that the whole took 800 milliseconds does not by itself decide what to do, but if you learn that a specific query accounts for most of the breakdown, the place to intervene narrows to one. This breakdown cannot be reconstructed from a collection of averages.

The mechanism that keeps it one trace across services

To treat a request spanning multiple services as a single trace, Datadog uses a method called trace context propagation. As the official documentation explains, values such as the trace identifier and the parent span identifier are inserted into HTTP headers and carried along as the request flows through the system. The receiving side extracts those values and continues the trace, and Datadog stitches the individual spans into one distributed trace. What follows directly from this is that on a path where the identifiers are not carried, the pieces do not become one trace. If an uninstrumented mechanism sits at a junction and the headers are not passed on there, the downstream spans are recorded as a separate trace. When a trace appears to be cut off partway, checking whether the identifiers are being handed over at the boundary gets you to the cause faster than hunting for a slow service. The break shows up as a hand-off problem, not a performance problem.

Service and resource - two axes for reading

When reading traces, two vocabulary terms come up repeatedly. The official documentation explains a service as a building block of a microservice architecture, a grouping of endpoints, queries, or jobs. A resource represents a particular domain of the application, such as an instrumented web endpoint, a database query, or a job running in the background. A value like GET /productpage is given as an example of a resource name. A caution that follows directly from the definition is the design decision not to mix per-request values into resource names. Because a resource is positioned as representing a particular domain, if an individual identification number gets into the name, the same kind of operation is listed as separate things, and you can no longer view the trend as a group. This design matters when you handle endpoints where part of the path is variable. Deciding the naming up front avoids the situation where the screen later becomes unusable.

The time everything is visible and the time it is kept are decided separately

The first stumbling block in operations is that ingestion and retention are separate settings. According to the official documentation as of August 2026, ingestion controls let you send up to the full volume of traces, and they can be handled as targets for live search and analytics for 15 minutes. Retention filters, on the other hand, decide based on tags which spans are indexed on the Datadog side, and those are retained for 15 days. The setup the official documentation recommends is to ingest the full volume and then keep the traces that matter to the business for 15 days with retention filters. If you do not know about this separation, records appear to vanish in the middle of an investigation. In reality, the full volume is visible only for the most recent 15 minutes, and before that only what the retention filters selected remains. That is exactly why retention filter conditions are not something to think about after an incident. Traces containing errors, business-critical paths such as payments, and intervals where slowness is a problem need to be written down as conditions in advance.

When to start caring, and points that are easily confused

You start to think about traces when your monitored target changes from a single application to a collaboration of multiple services. While things run standalone, processing time metrics and logs suffice, but once calls start to chain, triage does not progress unless you can follow where the time went on a per-request basis. Here are three points that are easily confused. First, thinking of a trace as a kind of log. A log is a record of events, whereas a trace holds the structure of a single request itself and lets you walk the parent-child relationships. Second, thinking that because you configured full-volume ingestion, everything can be investigated later. The full volume is available for 15 minutes; beyond that it depends on the outcome of the retention filters. Third, thinking that one request corresponds to one span. A trace is made up of one or more spans, and its value lies in revealing the breakdown. The primary source for the terminology is Datadog's official documentation, APM Terms and Concepts. The retention and ingestion periods mentioned here are as described as of August 2026. The product-side mechanism for collecting traces and using them in investigation is explained in detail in the APM entry.