Custom Metrics

Overview

Custom metrics are metrics that you define and send in yourself, as opposed to the metrics that flow in automatically from Datadog's supported integrations. Numbers that only mean something to your own business belong here: the seconds until an order is confirmed, the number of retries, the count of records processed by an internal batch job. What matters in practice is how they are counted. The unit is not the metric name but the combination of a name and its tag values, so consolidating names into one and splitting by tags does not reduce the total. The allocation is determined by your plan and host count, and consumption is summed across the entire account. There are many entry points for submission, and metrics generated from logs or spans consume the same allowance, which makes this an area where growth is easy to miss.

What supported integrations collect, and what you send yourself

Datadog ships a large number of integrations, and metrics that arrive from services on the supported list are treated as standard. Everything else, meaning metrics that you define and send yourself, is a custom metric. As of August 2026, the official documentation cites submission via DogStatsD and custom Agent checks as the representative examples, and explains that metrics coming from Marketplace integrations, or from integrations not on the supported list, are also counted as custom.

There are also paths that do not appear in the table. When you send directly to the HTTP API, when you send from AWS Lambda, and when you generate metrics from logs, APM spans, or RUM events, the resulting metrics are treated as custom. Some standard integrations such as MySQL and PostgreSQL let you add collection targets yourself, and whatever you add is counted on the custom side. The first thing to understand is that drawing the line at "do I remember sending this myself" will get it wrong.

The unit of counting is the combination of tag values, not the name

The official documentation defines one custom metric as "a unique combination of a metric name and tag values." The tag representing the host is part of that combination. In the example the documentation gives, a single name request.Latency with two possible values for the endpoint tag and two for the status tag already comes to 4 custom metrics. This way of counting produces results that run against intuition. Even if only 20 names appear on your dashboards, if each carries 3 tags and each tag can take 5 values, the actual count grows multiplicatively. Trimming the names from 20 to 10 changes nothing if the lost classification is simply moved into tags. What actually reduces the count is narrowing the variety of tag values, not the names. This multiplicative property is inseparable from Tag design; if you treat tag design as a matter of presentation, the count grows under your feet. The aggregation used for billing adds one more layer. According to the official billing documentation, what is billed is the monthly average of the counts observed each hour. A one-day spike from an experiment will not blow up the whole month, but metrics that stream continuously go straight into the average.

The allocation is set by host count, and consumption is summed across the account

According to public information as of August 2026, the allocation per host is 100 custom metrics on Pro and 200 on Enterprise. What changes the practical meaning is the summing rule that the official billing documentation spells out: the allocation is not handed out per host, but pooled and evaluated across the entire account. So if you monitor 10 hosts on Pro, your total allowance is 1,000. Even if one application server sends 400, you are not over as long as the other 9 hosts are modest. Conversely, checking whether each host stays within 100 tells you nothing; what you need to watch is the account-wide total. Because adding hosts also raises the allowance, there is a slightly perverse relationship in which the work of reducing what you monitor also eats into your headroom. On overage, the official billing documentation explains that "for every 100 custom metrics over the allocation, you are charged at the unit price stated in your plan." The unit price itself depends on your contract, so cost estimates have to be checked against the contract and the billing statement. Filling this in by guesswork does not produce a number, so the practical order of operations is to pin down the contract-side unit price as soon as an overage comes into view.

Decisions to make before sending that pay off later

Naming and value constraints are worth settling first, because fixing them later severs the data from its history. Under the official documentation's rules as of August 2026, a name must start with a letter, may only contain ASCII alphanumerics, underscores, and periods, and cannot contain Unicode. The maximum length is 200 characters, but the documentation recommends staying under 100. And names are case-sensitive. This last point is a frequent source of accidents: if one service sends order.Latency and another sends order.latency, they appear as two separate metrics, and each graph draws only half of what it should. There are constraints on the value side too. Values must be numbers that fit in 32 bits, and sending dates or timestamps as values is not an intended use. The acceptance window for timestamps is 10 minutes into the future and 1 hour into the past. This window constrains your design. Operations such as re-sending the previous day's data in bulk from a nightly batch job, or pouring in the measurements that piled up after recovering from an outage, simply do not work. If you need to backfill the past, you have to decide to use logs or another store instead of metrics. On submission rate, the official documentation states that no fixed limit is imposed. This is not reassuring. Not being stopped by a limit means submissions keep going through even as combinations keep multiplying, and the trigger for noticing becomes the bill or the weight of aggregation. If you manage Datadog Agent configuration through distribution, restricting the variety of values that go into tags on the configuration side is cheaper than hunting for them afterward.

What you lose without it, and the counting mix-up

What standard integrations give you are metrics that look the same at every company: CPU utilization, queue length, response distribution. On the other hand, "seconds until a payment is confirmed," "on which retry it succeeded," and "how many internal closing jobs remain" are numbers that do not exist outside your business, so nobody will measure them for you. Monitoring without custom metrics can say that the servers are alive, but it cannot say that the business is running. That gap is what really hurts during incident response. It decides whether you can detect the situation where every infrastructure metric stays green while orders alone have been stalled for 30 minutes. The most prominent mix-up is the belief that reducing the number of names reduces the count. What is counted is combinations, so the moment you consolidate names and split by tags, the total does not move. The other is overlooking paths you did not think you were sending through: metrics generated from logs or spans consume the same allowance. When the person who added the generation setting and the person who notices the count increase sit in different departments, pinpointing the cause takes time. Knowing the boundaries with neighboring concepts also keeps you from getting lost. Metric is the general term for a numeric time series itself, and whether it is custom is a classification based on where it comes from. The phenomenon of the count growing is treated as Cardinality. The primary sources for the counting rules are Datadog's official documentation pages Custom Metrics and Custom Metrics Billing.