Metric
A metric is a measurement that pairs a measured numeric value with the time it was measured and the tags that describe what was measured. Each individual record is stored as a time series, a sequence of points ordered by time, and because it works equally well for graphing, aggregation, and threshold evaluation, it forms the foundation of monitoring that tracks the state of a system.
Overview
A metric is time series data in which pairs of a timestamp and a value are arranged in time order; Datadog ingests them as data points that each carry a value and a timestamp. Unlike logs, which record events one by one, a metric is stored as a number rounded off at the moment of measurement, so you can keep long periods cheaply and comparisons across time ranges and targets finish quickly. It is the first thing you look at when spotting the onset of an anomaly across the whole picture, estimating capacity, or raising an alert on a threshold, and it is used under a division of labor in which pinpointing the cause is handed off to logs and traces.
The triple of time, value, and tags
A metric is a record that pairs a single numeric value measured for some target with the time it was measured. Datadog ingests this as a data point carrying a value and a timestamp, and stores points with the same name, connected in time order, as a time series (as of September 2026; Source: Metrics). The third element is the tag: because which host and which environment the value was measured in is attached to the point itself, you can later switch targets and compare them. As a finer detail of ingestion, sub-second timestamps are rounded to the nearest second, and when multiple points arrive for the same timestamp, the one that arrives later overwrites the earlier value. Sending the same name and tags for the same second through the API any number of times does not add points, so a value you want to measure in finer slices has to be sent under a different name or different tags.
It becomes the foundation because it is cheap to keep for a long time
The strength of a metric is that it has already been reduced to a number at the moment it is recorded. Compared with logs, which keep the full text of each event, the storage per point is small, so the same cost buys a much longer period. On Datadog Pro / Enterprise, metric retention is 15 months (as of August 2026; Source: Datadog Pricing), so you can put the load from the same month a year ago and the load in front of you on the same screen. Because they are numbers, sums and averages compute quickly, and switching views, such as collapsing 100 hosts into a single line or, conversely, splitting them out host by host, finishes right away. Since cheap, long, and fast all come together, the established practice is to put the entry point of monitoring on metrics.
The questions it can answer differ from those of logs and traces
Metrics, logs, and traces do not substitute for one another; the questions each is good at are distinct. Metrics show "since when, and how bad" as an overall picture, logs show "what happened at that moment" as individual records, and traces show "which operation consumed the time" as the path of a single request.
| Signal | Unit of record | Questions it answers well | How cost grows |
|---|---|---|---|
| Metrics | Time + value + tags | Overall trends and the onset of anomalies | Number of time series, determined by combinations of name and tags |
| Logs | Full text of each individual event | Details and evidence of individual events | Volume ingested and number of events indexed |
| Traces | Path of a single request | Identifying slow operations and dependencies | Volume of spans ingested |
Datadog's own documentation also guides you through the sequence of confirming the health of the environment at a glance with metrics, then digging in with logs and traces once you find a problem (as of September 2026). When observability is described in terms of three signals, metrics play the role of the surface you look at first.
What to make a metric, and what to leave in logs
The practical dividing line is to put things that can be answered by counting and comparing magnitudes into metrics, and things you will want to read back one at a time into logs. Order counts, queue lengths, and the distribution of response times suit metrics; which user's which order failed for what reason suits logs. The thing to watch out for here is not to put values whose variety grows without bound, such as user IDs or request IDs, into tags. Because the number of combinations of name and tags directly becomes the number of time series, custom metrics billing jumps (for how this is counted, see cardinality). The routes for sending to Datadog are integrations, Agent checks, DogStatsD, or the API, and whichever route you send through, the way you query and graph after storage is the same. Whether something counts as a custom metric, however, is determined by the route and the name (for details, see Datadog Metrics).
The graph is not the metric itself
What is stored is only the sequence of points; the lines and bars you see on the screen are the result of grouping those points into fixed time buckets and drawing them. Even for the same single time series, the shape changes depending on whether the grouping is a sum, an average, or a maximum. When you widen the displayed time range, the width of each point widens too, so a spike that was visible over a short range can look flat over a long one. Before judging that there is no problem because the graph is flat, get into the habit of checking which time range and which aggregation the chart was drawn with.
Looking only at the average gives you a number that is nobody's experience
Another stumbling point is describing response time by the average alone. Even in a state where 90 percent of users get a response in 100 milliseconds and 10 percent are kept waiting 5 seconds, the average settles at a calm-looking 590 milliseconds, and the 10 percent who are actually suffering disappear from the number. For values that have a distribution, the basic practice is to view them alongside the 95th percentile and the maximum. In Datadog, the metric type you choose at submission time determines whether you can look at the distribution later. Deciding how you will want to view a value in the future before you send it in a form that can only produce an average reduces the effort of rebuilding it.