Tagging

What tags connect, seen through the map of reserved keys

A tag is a string in key:value form, where the key represents the axis of classification and the value the specific content. The real worth of tagging is not mere organization; it lies in tying together different kinds of data, metrics, traces, and logs, with the same label so you can move between screens (as of August 2026, source: Getting Started with Tags). At the center of this tying-together are the reserved keys.

The official documentation recommends that in environments where hosts are frequently replaced, such as containers and the cloud, you aggregate and view by service rather than looking at server A and server B individually. The concept of a tag itself is also organized in the glossary entry for tag.

Four routes for attaching tags, plus inheritance

There are four ways to attach tags, and they can be combined: writing them in the configuration files of the Agent or integrations, attaching them in the Datadog UI, attaching them through the API, and attaching them when sending metrics with DogStatsD (as of August 2026, source: Getting Started with Tags). What tends to be overlooked here is the inheritance mechanism: tags attached at the host level are automatically passed down to all metrics, logs, and traces tied to that hostname. Inheritance is convenient, but when the same key is inherited from multiple origins it becomes a source of confusion. The official documentation gives the example of setting service:my-host on a host and service:my-service on a pod running on it, so that the data inherits both tags, and recommends using a different key name such as infra_service for the host-side role. Keeping at least one person on the team who can explain "through which route was this tag attached" is the practical breakwater for finding tag duplication and contradictions early.

Unified Service Tagging - the three-piece set of env, service, and version

The configuration of consistently attaching three of the reserved keys, env, service, and version, to all telemetry is treated so specially that it has its own name, Unified Service Tagging (as of August 2026, source: Unified Service Tagging). When these three are in place, feats become possible such as pinpointing the impact of a deployment from traces and container metrics filtered by version, or moving between traces, metrics, and logs while keeping the same tag condition. version is a tag expected to change with every deployment; different code gets a different version. Where this pays off is during incident response. The hypothesis "the error rate went up right after the release" can be verified in a few minutes with a version tag just by lining up the error rates of the old and new versions, but without it, it becomes manual work of visually matching deployment times against graphs. If there is even a slight chance you will use APM, this three-piece set alone is worth setting up from the start.

Why conventions cannot be swapped out later

Thinking you can fix tag conventions later is dangerous. The reason lies in the structure of metrics. A time series is identified by "the combination of metric name and tag values," so the moment you change a tag, it becomes a different time series. In other words, the history before the convention change and the history after do not connect, and the trend graph for the past year breaks at the date of the change. Monitor and dashboard queries also reference tag names directly, so a swap goes hand in hand with an inventory of every query. That is exactly why you decide conventions at the start, with the format constraints in mind. A tag string must start with a letter, the usable characters are Unicode letters, digits, underscores, minus signs, colons, periods, and slashes, and anything else is converted to an underscore. The length is up to 200 characters including the key, the colon, and the value. Furthermore, span tags and metric tags are normalized to lowercase, so it is safer to avoid camel case. Normalization on the cloud provider side also varies; the official documentation gives the example of AWS converting TestTag to testtag and Alibaba Cloud converting it to test_tag (as of August 2026, source: Getting Started with Tags). Starting the conventions simply with "all lowercase, underscores between words, key vocabulary managed in a list" is the initial setup with the fewest regrets.

Cardinality and how it rebounds on billing

Tag design is directly tied not only to usability but to the size of the bill. However, the way it rebounds differs by data type. Custom metrics count each "unique combination of metric name and tag values" as one billable item, so attaching a tag with many distinct values (user ID, container ID, request ID, and so on) to a metric multiplies the number of time series (as of August 2026, source: Custom Metrics). This is the so-called cardinality accident. On the other hand, logs are billed by ingested volume and the number of indexed events, and trace spans by ingested GB, so adding tags is not in itself a primary driver of billing. Translating this asymmetry into a convention gives one line: "On logs and traces, attach tags useful for investigation freely. But the keys of tags attached to metrics are limited to those whose values are finite and few." If you want high-cardinality analysis, the proper approach is not to add tags to metrics but to use logs, which retain raw data, as the receptacle. Log billing is based on ingested volume and does not depend on the number of distinct tags. It is dangerous here to think of the DISTRIBUTION type of custom metrics as the receptacle. DISTRIBUTION is also counted by the combination of metric name and tag values, and moreover generates 5 times as many custom metrics by default (and even more when percentile aggregation is enabled), so using it as the place for high-cardinality tags actually inflates the bill (as of August 2026, source: Custom Metrics Billing). The overall picture of pricing is covered in the pricing guide.

Three rules for operating as a team

Finally, here are three operating rules proposed to keep the conventions from becoming a plan on paper only. First, manage the list of tag keys in a single document and put the addition of new keys through review. Because anyone can attach tags through any route, if left alone the vocabulary drifts toward anarchy where env, environment, and stage coexist. Second, make the team tag mandatory on all resources. This tag, which is also among the official reserved keys, wipes out the incident-time question "whose is this?" and also becomes the basis for cost allocation. Because Datadog's billing reports can break down usage by chosen tags (up to 3) (as of August 2026, source: Getting Started with Tags), using team as the axis produces Datadog costs per team mechanically. Third, once a quarter, take inventory by looking over the list of tag keys actually in use. Keys that stray from the conventions are cheapest to weed out early in their proliferation. Once tagging is in place it becomes like air, but what maintains that air is not a mechanism but small operating practices like these.