Built-in Service Metrics

Dash0 automatically generates a small set of metrics from your spans to power the Service Catalog and the Service Map. You do not need to emit these metrics yourself, and they are not billed as custom metrics.

dash0.spans.redCopy

dash0.spans.redCopy is the metric behind every request rate, error rate, and latency percentile shown in service views. It captures the three RED signals for each service and operation in a single exponential histogram.

RED stands for the three golden signals of service performance:

• Rate: Requests per second, used for traffic volume and capacity planning.
• Errors: Error percentage, used to track service health and reliability.
• Duration: Latency distribution, used for user experience and SLO compliance.

Metric Properties

How RED Signals Are Derived

All three RED signals come from the same histogram:

• Rate: Histogram count over time gives requests per second.
• Errors: Filter by otel.span.status.code = STATUS_CODE_ERRORCopy, then count.
• Duration: The histogram's bucket distribution provides latency percentiles (p50, p95, p99, and so on).

Attributes

Each data point carries the following attributes, which you can use to group, filter, and alert:

Relationship to Operation Names

An operation in Dash0 loosely corresponds to an API endpoint that a service exposes: an HTTP route it serves, a gRPC method it implements, a database query it answers, or a queue it consumes from. It describes what the service does when something calls it, not the outgoing calls the service itself makes to other systems. In OpenTelemetry terms, operations are derived from SERVERCopy and CONSUMERCopy spans, and from root spans that represent a unit of work; CLIENTCopy and PRODUCERCopy spans, which represent outbound HTTP requests, database calls, or messages the service sends, are not treated as operations of the calling service. See Operations for the full set of rules.

dash0.spans.redCopy is grouped by dash0.operation.nameCopy, and the two are designed together. A RED histogram is only useful if its dimensions have bounded cardinality and are stable over time, and operation names are what make that possible:

• Bounded cardinality: Raw OpenTelemetry span names often embed per-request values such as IDs, query strings, or full URLs. Using span names directly as a metric dimension would create a new time series for every unique path (for example GET /users/123Copy, GET /users/124Copy, and so on) and quickly exhaust cardinality budgets. dash0.operation.nameCopy collapses these into parameterized forms like GET /users/{id}Copy, which keeps the histogram's per-service dimensions finite and stable.
• Cross-instrumentation consistency: Dash0 derives dash0.operation.nameCopy from OpenTelemetry semantic conventions, so HTTP, database, messaging, and RPC spans all get comparable names regardless of which instrumentation library produced them. This is why the Service Catalog and Service Map can show a single "Operations" list per service with consistent rate, error, and duration numbers.
• The "per-operation" numbers come from this grouping: The per-operation request rates, error rates, and latencies shown in the Service Catalog are literally dash0.spans.redCopy sliced by dash0.operation.nameCopy (and dash0.operation.typeCopy). Anything that affects operation naming, such as overriding dash0.operation.nameCopy on a span, directly changes how RED is grouped.

For this reason, dash0.spans.redCopy is only generated after operation names have been derived.