Monitor

Overview

A Datadog monitor is an evaluation definition that brings together a search query that narrows down the targets, an aggregation method that collapses multiple values into one, the time window over which values are examined, and the threshold at which a violation is declared. Settings for the notification recipients and the notification body are attached to it, and when the condition is met it is sent out as an alert. The key design point of a monitor is that the evaluation definition and the notification settings live in separate layers: you can swap only the recipients while leaving the condition unchanged, or tighten only the condition while keeping the recipients. Unlike collection and visualization, which are the entry points of monitoring, a monitor is a mechanism for "making people act," so how you design its firing directly determines the operational load.

A monitor is an evaluation expression, not a box for notifications

The name monitor tends to suggest a bundle of notification settings, but what sits at the center is an evaluation expression. A search query that decides which data to look at; an aggregation method that collapses multiple values into one, which for metric-based threshold conditions is one of average, maximum, minimum, or sum; an evaluation window that says how much time to judge over; and a threshold at which a violation is declared. Only once these four are decided can a monitor hold a state. The recipients and the notification body are nothing more than settings for the output that runs when that state changes.

The practical benefit of separating evaluation from notification kicks in once operations mature. The work of examining whether a threshold is appropriate and the work of deciding whom to notify differ in both the people responsible and the review cycle. Because the design does not break one side when you touch the other, a monitor can be grown over a long time.

Grouping determines the granularity of alerts

A monitor with no grouping specified sends only one notification when the condition is met. On the other hand, when you group by a dimension such as host or service, each target is evaluated independently and a notification goes out per target. Datadog distinguishes these two by calling them Simple Alert and Multi Alert. When some dimensions are dropped in the settings for how notifications are combined, the dropped dimensions are listed on the screen as Sub Groups. Which to choose is not a matter of technical preference but a question of operational design: where do you place the unit of response? If you split by host, 100 notifications arrive when 100 hosts go down at once, and the recipients are busy working through notifications before they can grasp the spread of the outage. Conversely, if you combine too much, the whole monitor is treated as recovered when only one host has recovered, and the remaining anomalies become invisible. The criterion for judgment is "will the person who receives this notification take the same next action or not?" If the action is the same, combine; if it differs, split. Deciding this one point first keeps the threshold discussion from going around in circles.

Decide the behavior for when data stops arriving, up front

The pitfall of a monitor shows up not so much when a threshold is exceeded as when data stops arriving. For handling missing data, Datadog provides Evaluate as zero, which evaluates it as zero; Show last known status, which keeps the immediately preceding state; Show NO DATA, which displays the missing-data state; Show NO DATA and notify, which goes as far as notifying; and Show OK, which treats it as healthy. If you leave the default in place without thinking, you create a state in which a server whose collection has stopped looks "quiet and healthy." The point to grasp here is that the waiting time before data is judged missing is not itself exposed as a setting. The official documentation as of August 2026 states explicitly that the width of this judgment cannot be changed by the user. When you write default_zero() in the evaluation expression, the behavior of treating missing data as zero is fixed on the expression side, so how the expression is written takes effect before the missing-data setting does. The automatic resolution setting is another item that is easily misunderstood. This is a feature that returns a monitor whose data reporting has stopped to the resolved state after a certain time; it is not a mechanism that detects a return to normal by dropping below the threshold. The documentation also recommends leaving it disabled as a rule. If you want to detect recovery to normal, the coherent design is to set a separate recovery threshold.

Handling evaluation delay and maintenance windows

Metrics ingested from cloud providers reach Datadog later than the actual time. If you evaluate while ignoring this lag, you will look at the most recent interval, which has not yet been written, and judge it as missing. A monitor has a setting that shifts evaluation back by a fixed number of seconds, and as of August 2026 the upper limit you can specify is 86400 seconds, that is, 24 hours. The official documentation recommends a delay of about 15 minutes for cloud metrics that are backfilled late, and about 60 seconds for expressions that include division. The interval at which evaluation runs is basically determined automatically from the length of the evaluation window. There is a setting to move it onto a daily, weekly, or monthly schedule, but apart from that you cannot choose the interval directly. As of August 2026, windows under 24 hours are evaluated every 1 minute, 24 to 48 hours every 10 minutes, and 48 hours or more every 30 minutes. The reason a long window makes the response sluggish is not a property of the threshold but that the evaluation interval itself stretches. If you want to silence a monitor only during planned maintenance, do not touch the conditions on the monitor side; use Downtime, which stops notifications for a specified period. The accident of temporarily loosening a condition and forgetting to restore it is the typical way monitoring breaks while remaining in form only. It helps to understand that the mechanism for stopping is kept separate precisely to avoid this accident.

When this concept matters, and common misconceptions

You start thinking seriously about monitors when you move past the stage of merely collecting and viewing and enter the stage of notifying people of anomalies. What actually trips people up there are the following three assumptions. First, the assumption that one monitor corresponds to one alert. The moment you group, a single monitor produces as many independent notifications as there are targets. Second, the assumption that not firing is proof of health. Unless you have worked out the handling of missing data, silence means not health but a halt in observation. Third, the assumption that to reduce false positives you should tighten the threshold. If momentary spikes are the cause, lengthening the evaluation window to smooth out the spikes, rather than moving the threshold, avoids missing the sustained deterioration you actually want to detect. The threshold value itself can be corrected any number of times later. What is hard to correct is the grouping granularity and the handling of missing data; because these are tied to the structure of who receives notifications, changing them later means renegotiating agreement on the operations side. When creating the configuration, it pays to spend your time on these two. The primary source for the specification can be checked in Datadog's official documentation, Configure Monitors. Content that goes further into choosing among monitor types and designing notification text is covered in the guide "Monitors and Alerts."