Enable endpoint-level metrics for SDv1 services

• Latest Dynatrace
• How-to guide
• 8-min read
• Updated on Jun 30, 2026

With Enhanced endpoints for SDv1, every detected endpoint on your Service Detection v1 (SDv1) services automatically produces metrics: response time, throughput, and failure count. No key request configuration is needed. These metrics are available in Dashboards, Notebooks, Service-Level Objectives, alerting, and Services. They're the same dt.service.request.* metrics produced by Service Detection v2 (SDv2) and OpenTelemetry services, so a single dashboard query works across all service detection versions.

Benefits

The Enhanced endpoints feature replaces the need to configure key requests. Existing key requests are preserved—any endpoint you previously configured as a key request keeps its name and appears alongside the new automatically detected endpoints. Every detected endpoint gets its own response time, throughput, and failure count automatically, with no manual selection needed.

Use endpoints and metrics

Endpoints and their metrics appear in Services.

From there, you can view endpoint metrics, open traces for each endpoint, and perform more actions using the Actions menu.

Services app showing the Endpoints section with four endpoints and their metrics

The Endpoints section shows each endpoint with its response time, throughput, and failure rate. You can sort by any column to find your slowest or most-called endpoints. To investigate a specific endpoint, select it to see its time-series charts and traces. To see the underlying URL paths, select an endpoint and select View all URLs to open Distributed Tracing. For more information on how endpoints differ from URLs, see Endpoints vs URLs.

You can also use endpoint metrics in:

Metric keys

Feature availability

Enable Enhanced endpoints

You can activate Enhanced endpoints for the entire environment, a specific host group, or a Kubernetes namespace and cluster.

Naming for HTTP-related endpoints in SDv1

Dynatrace uses the http.route span attribute to generate names for HTTP-related endpoints.

Services that provide http.route—Spring Boot, Express, FastAPI, ASP.NET Core, Django, Flask, and similar frameworks—get descriptive endpoint names automatically. Services that don't emit http.route (NGINX, Apache, IIS, and most reverse proxies and gateways) get a stable name from the automatic naming heuristic, and fall back to generic names like GET /* otherwise. For the general naming mechanism, see Naming for HTTP-related endpoints.

For SDv1 services specifically, existing request naming rules continue to apply to endpoint names. Existing key requests are also preserved—any endpoint you previously configured as a key request keeps its name and appears alongside the automatically detected endpoints. You don't need to create new key requests because every endpoint gets individual metrics automatically.

Automatic naming for services without http.route

Dynatrace SaaS version 1.341+

For services that don't emit an http.route span attribute, Dynatrace derives a fallback route based on the URL path. The derived value is stored as http.route and used in endpoint names. Dynatrace also adds the supportability.is_http_route_derived attribute to mark routes that were derived this way (not received from instrumentation).

Dynatrace derives a fallback route value by scanning the URL path segment by segment and truncating at the first "volatile-looking" segment. Four rules detect volatile segments:

If the first segment of the URL path matches one of the rules, the derived route falls back to the /* value, which resembles the previous endpoint naming behavior.

Only the first four segments of the URL path are scanned. If no rules match within those four segments, the full four-segment path becomes the derived http.route. For example, /company/department/unit/team/group results in /company/department/unit/team.

Volatile and non-volatile placeholders in naming rules

Naming rule placeholders are either non-volatile (stable values like {HTTP-Method}) or volatile (high-cardinality values like {URL}). Dynatrace handles them differently to prevent endpoint explosion.

Include low-cardinality URL path in endpoint names

Dynatrace version 1.339+

When you want endpoint names based on the URL path without a separate endpoint for every unique value, use the {URL:Path-Clean} placeholder. With this placeholder, you get per-path endpoints while keeping cardinality under control.

The {URL:Path-Clean} placeholder works similarly to the {URL:Path} placeholder, except Dynatrace replaces volatile segments—UUIDs, IPv4 and IPv6 addresses, and IBANs—with stable markers before the URL path becomes the endpoint name. It applies the same logic as the Remove UUIDs, IP addresses and IBANs from URLs option available in the request naming settings, plus any custom cleanup rules you've defined.

The following table compares the output of both placeholders.

Request attribute values in endpoint names

If your naming rules use the {RequestAttribute:_} placeholder, turn on Resolve request attributes for SDv1 request naming rules to replace the placeholder with actual values. This produces separate endpoints per request attribute value, giving you finer-grained metrics. See Enable Enhanced endpoints for detailed instructions.

Changes to span names in Distributed Traces

With all web requests now covered by an endpoint, span names in Distributed Tracing show the endpoint name rather than the URL path.

Distributed Tracing app showing span with the name of the endpoint, URL path, and service name

Fine-tune endpoint names

Services that use generic endpoint names like GET /* group all traffic under a single endpoint, which limits your ability to set targeted SLOs, alerts, and dashboard filters. To get per-endpoint visibility for these services, identify which services need attention and then create request naming rules to produce specific endpoint names.

fetch spans
| filter isNull(`http.route`)
      and request.is_root_span == true
      and isNotNull(`http.request.method`)
| summarize urls_without_http_route = countDistinct(url.path), by: {dt.entity.service, dt.service.name}
| sort urls_without_http_route desc
| limit 1000

fetch spans
| filter isNull(`http.route`)
      and request.is_root_span == true
      and isNotNull(`http.request.method`)
      and dt.entity.service == "SERVICE-XXXXXXXXXXXXXXXX"
| summarize request_count = count(), by: {http.request.method, url.path}
| sort request_count desc
| limit 100

Find URL paths for a specific service in the Services app

1. Go to Services > Explorer and select your service.
2. In the Endpoints section, select the GET /* endpoint.
3. Select View all URLs to open Distributed Tracing with URL paths visible.

Services app showing the View all URLs button highlighted in the Endpoints section

The results show you the actual traffic patterns. For example, you might see /books, /books/403, /books/405, and other paths grouped under a single GET /* endpoint. These distinct URL paths are good candidates for a request naming rule.

Distributed Tracing showing a GET /* endpoint with distinct URL paths like /books, /books/403, and /books/405 grouped underneath

Create a request naming rule

Create request naming rules to define specific endpoint names based on URL conditions. Request naming rules are configured per service—your existing per-service naming rules continue to apply when Enhanced endpoints is active. For example, if your service handles /books/* requests, you can create a rule that produces GET /books, POST /books, and DELETE /books endpoints instead of a single GET /*.

View your new endpoints

After the naming rule takes effect, you should see specific endpoints that match your rule. Each endpoint has its own metrics for response time, throughput, and failure rate.

Distributed Tracing showing specific endpoints GET /books, DELETE /books, and POST /books with individual URL paths grouped under each

With specific endpoints in place, you can use them in dashboards, SLOs, and alerting as described in Use endpoints and metrics.

Manage endpoint cardinality

After configuring request naming rules, use the Endpoint Cardinality Dashboard to monitor how many endpoints each service produces and identify where you may need to tune your rules.

Endpoint Cardinality Dashboard showing services ranked by distinct endpoint count, with SpringBoot Distributor at 16 endpoints and other services below

The dashboard shows the maximum distinct endpoint names across all services and ranks services by their endpoint count. If a service produces an unexpectedly high number of endpoints, review its request naming rules to ensure volatile placeholders aren't creating excessive cardinality.

The Endpoint Cardinality Dashboard ranks your services by endpoint count, helping you identify where to adjust naming or detection rules to control cardinality.

To view services with the most endpoints

If high-cardinality request attributes produce an excessive number of endpoints, turn off Resolve request attributes for SDv1 request naming rules to reduce endpoint volume. See Enable Enhanced endpoints for detailed instructions.

Static resource requests

When the Enhanced endpoints feature is active, static resource requests (Image, Binary, CSS, and JavaScript) are unmuted and grouped into a single Static resources endpoint with the same metrics as other endpoints.

To mute static resource requests, follow the steps in Mute monitoring of service requests. After muting, the Static resources endpoint no longer appears in the endpoint list, and these requests don't count toward overall service metrics.

You can add or edit filename extensions that count toward the Static resources endpoint. For details, see Configure resource request detection. Existing resource request detection configuration still applies.

Licensing considerations

The Enhanced endpoints for SDv1 feature collects per-endpoint metrics individually rather than aggregating non-key-request endpoints into a single NON_KEY_REQUEST entry. The additional metric volume is typically within the included allowance for Full-Stack Monitoring.