Resource (APM)
An APM resource is the unit in Datadog APM that represents a specific operation within a service; for a web service it is an endpoint, for a database service a normalized query, and otherwise a background job. Spans with the same resource name are aggregated, and the resource becomes the axis for reading trends.
Overview
A resource is the APM unit that represents one operation within a service, named by a pair of HTTP method and route such as GET /productpage, or by an operation name such as ShoppingCartController#checkout. In a web service, dynamic endpoints line up under the fixed span name web.request, and in a database service, individual queries line up under db.query. At ingestion time, numeric IDs, GUIDs, and query parameter values are replaced with {num} / {guid} / {val}, so the same operation is aligned to the same name. You care about it when the resource list swells with ID-laden names and becomes unreadable, and when you want to recover a distinction that normalization erased.
A name that points to one operation within a service
An APM resource is the unit in Datadog APM that represents a specific operation within a service (as of September 2026, Source: APM Terms and Concepts / Resource Page). The official documentation gives three typical cases: instrumented web endpoints, database queries, and background jobs. The name examples shown are a pair of HTTP method and route such as GET /productpage, and an operation name such as ShoppingCartController#checkout. For a web store service, endpoints such as checkout, cart update, and adding a product each become a resource through auto-instrumentation. Trace metrics are aggregated per resource and can be used in dashboards and monitors, and a dedicated resource page is created automatically.
Two layers: the span name is fixed, the resource name is variable
The shortcut to grasping resources is to think of the span name and the resource name separately. In the official documentation's explanation, the dynamic endpoints of a web service are grouped under the fixed span name web.request (as of September 2026, Source: APM Terms and Concepts). The queries of a database service line up under the span name db.query. In other words, the span name is a fixed word that expresses "what kind of work," and the resource name is a variable word that expresses "which operation within that work." Because of these two layers, spans with the same web.request name are aggregated as separate rows if their resource names differ, and combined into one row if they are the same. Which service an endpoint belongs to is also decided by the name of this entry span.
- A request arrives and an entry span is created (span name =
web.request) - A resource name is attached to the entry span (HTTP method and route, for example
GET /productpage) - Spans with the same resource name are grouped and aggregated as trace metrics
- They appear on the resource page as graphs of request count, errors, and latency
Normalization at ingestion - {guid} / {num} / {val}
At ingestion time, Datadog replaces random GUIDs, numeric IDs, and query parameter values contained in span names and resource names with fixed strings. The official documentation calls this quantization (as of September 2026, Source: Quantization of APM Data). GUIDs become {guid}, numbers of 6 or more digits surrounded by non-alphanumeric characters and numbers at the end of a string become {num}, and query parameter values become {val}. The replacement extends to the names of trace metrics, the resource_name tag of those metrics, and the resource names and span names of all ingested spans. For example, span names that contain a GUID at the end are aligned to something like find_user_{guid}, and the metric name takes the form trace.find_user_guid.hits. If a resource name ends in a number like temp_128390123, it is aligned to temp_{num}.
Why align them - to stay inside the bounds of cardinality
The official documentation explains that the reason normalization is on by default is to curb name pollution. It is a measure to avoid listing spans and resources that are the same operation for analysis purposes as different things because of random strings (as of September 2026, Source: Quantization of APM Data). Because resource names become tags on trace metrics, the number of distinct names directly becomes the number of series. If a URL containing an order ID or raw SQL with embedded values became the name as is, one series would be born per request, and neither the list nor the aggregation would be readable. The nature of that growth is left to the Cardinality entry. When the default replacement is not enough, either set the resource name yourself on the instrumentation side, or write your own replacement rules in the Agent's apm_config.replace_tags. However, the official documentation cautions that changing names creates new metrics and tags, so queries that depended on the post-replacement names will need to be updated.
Metrics visible on the resource page and the definition of an endpoint
A resource page is generated automatically for each resource (as of September 2026, Source: Resource Page). The default graphs are four: Requests and Errors, Errors, Latency, and Avg Time per Request, and the latency distribution appears alongside. The dependency map narrows the scope to requests that pass through the selected service and resource, and shows upstream and downstream service dependencies as a flow diagram. The span summary is a table that, for traces containing that resource, lists per span the average number of occurrences per trace, the percentage of traces that include it, the average duration, and the average share of execution time; it is available only for resources that include the service's entry span. When the resource corresponds to an endpoint, that is, an HTTP resource the service exposes at a specific URL path, a definition section is added. To look deeper into the database query side, Database Monitoring is the place, and which spans remain in a searchable form is the responsibility of the Retention Filter entry.