Composite Monitor
A composite monitor is a Datadog monitor type that combines the states of existing monitors with a logical expression using && / || / ! and notifies you only when the expression is true. Because it does not own the monitors it uses as components and only uses their results, the original monitors' configuration and notifications remain as they are.
Overview
A composite monitor is a Datadog monitor type that connects existing monitors you select, such as monitor A and monitor B, with a logical expression like a && b and consolidates them into a single state. Up to 10 monitors can be used as components, and a composite monitor cannot itself be a component. The expression is evaluated against whether each component's state is one of Alert / Warn / No Data, that is, "a state worth notifying about," and the composite monitor's state is determined from that result. You care about it when you want to build a notification that a single condition cannot express, such as "fire only when CPU is high and the error rate is also high."
Use existing monitors as components and consolidate them with a conditional expression
A composite monitor is a type that combines individual Monitors to define a more narrowly scoped notification condition. Select monitors A and B and write a logical expression such as A && B, and the composite monitor fires when both simultaneously reach values that satisfy their conditions (as of September 2026, Source: Composite Monitor). In terms of configuration, the composite monitor is independent of its components. Changing the recipients on the composite side does not change the components' recipients, and deleting the composite monitor does not delete the components. Since the composite monitor does not own its components and only uses their results, the same component can be referenced from multiple composite monitors. The character of this type is that you can layer conditions without breaking existing Alerts. The overall picture of the tooling for tuning how things fire is left to the Monitors explainer.
Component conditions - up to 10, no nesting of composites
Up to 10 monitors can be used as components, and you may mix simple alerts and multi alerts (as of September 2026, Source: Composite Monitor). However, a composite monitor cannot be used as a component, so nested composites cannot be built. Another condition is that the components share a common group. When you select a multi alert, the screen shows the grouping clause and the number of reporting series, which serve as clues for choosing partners. If you select components whose groups do not line up, a warning appears saying "this composite monitor may never trigger." Even with the same group, if there is no common reporting source a Group Matching Error is displayed, and since the state cannot be computed, it does not fire. You can still create it while ignoring the warning, so the warning means "it will not fire," not "it cannot be created."
Write the expression with labels a / b and 3 operators
The conditional expression is written with the labels a, b, c assigned to the components, together with logical AND &&, logical OR ||, and negation !, with parentheses controlling precedence (as of September 2026, Source: Composite Monitor). The 3 valid examples the official documentation shows are !(a && b), a || b && !c, and (a || b) && (c || d). When you select the second component, the default a && b is filled in. In practice, 2 patterns are built most often. "CPU is high and the error rate is also high" is a && b, a notification that does not fire on either alone. "Do not fire my own alarm while a dependency is down" is a && !b, with b being the dependency's monitor. When combining 3 or more, making the intent explicit with parentheses keeps whoever inherits it from misreading.
How the state is composed
A composite monitor has 4 states, Alert / Warn / No Data / OK, and the 3 other than OK are states "worth notifying about." The weights are in the order Alert 4, Warn 3, No Data 2, OK 1 (as of September 2026, Source: Composite Monitor). The operators act on this "worth notifying about." If A && B is true, the result is the lighter of A's and B's states; if A || B is true, it is the heavier one. For negation, if A is No Data it stays No Data, if A is worth notifying about the result is OK, and if it is not, the result is Alert. To have a composite monitor notify on No Data, "notify on missing data" must be enabled on both the components and the composite. If it is disabled on the composite side and the evaluation result is No Data, the last known state is used.
| Expression and component states | Composite monitor state |
|---|---|
A && B is true | The lighter of A and B (e.g., Alert and Warn gives Warn) |
A || B is true | The heavier of A and B (e.g., Alert and OK gives Alert) |
A && B with one side OK | OK (e.g., Alert and OK gives OK) |
!A with A being No Data | No Data |
!A with A worth notifying about | OK |
!A with A being OK | Alert |
Downtime applies separately to the composite and its components
Because a composite monitor and its components are independent of each other, Downtime also applies to only one side. The official documentation's example is a composite monitor C built as A || B (as of September 2026, Source: Composite Monitor). Placing a downtime on C stops only C's notifications; if A or B have their own recipients, those keep firing. Conversely, placing a downtime on component A does not mute C. In the example where A's env:staging group is muted, notifications from A are suppressed when that group enters a state worth notifying about, but the composite monitor sends notifications. For "do not fire anything during maintenance," you need to place a downtime on both the composite and the components.
The number of notifications is determined by common reporting sources
The number of notifications you receive is determined by the components' alert types. If all components are simple alerts, the composite is also a simple alert and notifies once when the conditions become true at the same time. If even one component is a multi alert, the composite is also a multi alert. When combining multiple multi alerts, only the reporting sources common to the components are evaluated (as of September 2026, Source: Composite Monitor). In the official documentation's example, when web01 through web05 report to A and web04 through web09 report to B, the composite looks only at the common web04 and web05. At most 2 notifications arrive per evaluation cycle. Matching is done on tag values only, without looking at keys, so adding a component C that reports service:web04 still lines up on web04. Components with different grouping dimensions can be combined if one contains the other, as with device,host and host.