Watchdog
Watchdog is the automatic anomaly detection feature built into Datadog. Without the user configuring any conditions or thresholds, it learns a baseline of the normal behavior of metrics and logs, finds movements that stray from it, and lets you know. Its role is to watch the area outside the net of the monitors you build yourself.
Overview
Datadog Watchdog is an automatic anomaly detection feature that works with no configuration. Datadog positions it as an AI engine that automatically surfaces alerts, insights, and root cause analysis (as of September 2026). It computes a baseline from normal behavior, and when APM error rates or latency, infrastructure metrics from major integrations, or sudden spikes in log errors stray from that baseline, it lists them as anomalies. It is the concept to care about in the early stage before you have built out your monitors, and when you want to reduce what slips through when something breaks somewhere nobody has written a condition for.
Anomaly detection built into Datadog that works with no configuration
Datadog Watchdog is the automatic anomaly detection feature built into Datadog. Datadog positions it as an AI engine that surfaces automatic alerts, insights, and root cause analysis from the observation data across the whole platform. Every capability is built in and requires no configuration (as of September 2026, Source: Datadog Watchdog). The heart of the mechanism is the baseline: it first computes the expected behavior of systems, applications, and deployments, then picks up movements that stray from it as anomalies. Unlike a monitor, where a person writes a condition such as "when CPU usage exceeds 80%", the defining characteristic is that Watchdog itself decides from history what counts as normal.
What it watches and what it does not
The targets Watchdog Alerts scans fall into three lineages. In APM it watches the error rate, latency, and hit count (request count) of every service and resource. To avoid noise, endpoints with fewer than 0.5 requests per second are excluded, and a change in hit count alone is ignored if it does not affect latency or error rate. In infrastructure it watches host memory and TCP retransmit rate from the System integration. In addition, 9 product integrations such as Redis / PostgreSQL / MySQL / Docker / Kubernetes and 7 kinds of AWS services such as S3 / RDS / Lambda are in scope. In logs it detects the appearance and sudden increase of warning and error logs at ingestion time (as of September 2026, Source: Watchdog Alerts). Put the other way around, custom metrics and business KPIs not on this list are outside Watchdog's field of view.
The history a baseline needs and how results appear
Detection begins only after history has accumulated. Metric anomalies need at least 2 weeks of history and log anomalies at least 24 hours, with the best accuracy at 6 weeks (as of September 2026, Source: Watchdog Alerts).
- History accumulates (minimum 2 weeks for metrics / 24 hours for logs)
- A baseline is computed from normal behavior
- Movements that stray from the baseline are detected as anomalies
- Displayed in the Watchdog Alert Explorer / APM service pages / Insights panel
- If you need a notification, create a Watchdog monitor to deliver it
The card for a detected anomaly shows its state (ongoing / resolved / expired, meaning it lasted more than 48 hours), its duration, tags indicating the affected scope, and, where known, the impact on users or services. Without this, when something breaks in a service nobody has written a monitor for, the first notice comes as a report from a user. Watchdog is the lookout that covers the period before people finish writing conditions and the places they left out.
The difference from monitors is who decides the conditions
With Monitors, you decide everything yourself: what to watch, the comparison condition, the threshold, and the notification target. Anomaly monitors, forecast monitors, and outlier monitors run on the same seasonality algorithms. Datadog directs you to create these when you want to watch metrics outside Watchdog's coverage or change the sensitivity (as of September 2026, Source: Watchdog Alerts). Watchdog scans everything without choosing targets, and the premise is that sensitivity is tuned on the monitor side. Notification handling also differs: a Watchdog detection is first something that appears in the list. To deliver it to a person, you create a monitor of type Watchdog from Monitors, narrow it by environment, alert category, and team, and then set the notification target (as of September 2026, Source: Watchdog Monitor). In other words, the division of labor is that a monitor watches "is the promise we made being kept", and Watchdog watches "is something unusual happening where no promise has been made".
The absence of a pricing line and the "no monitors needed" misconception
The Datadog pricing page has no standalone pricing line for Watchdog. In the Infrastructure Monitoring comparison table, the row "Watchdog: Automated insights" is checked only in the Enterprise column. The Log Management feature list also includes log anomaly detection by Watchdog Insights (as of September 2026, Source: Datadog Pricing). This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page. The misconception that easily grows from this is "with Enterprise we have Watchdog, so we do not need monitors." As the previous section showed, the coverage is limited to error rate, latency, hit count, the specified integrations, and log spikes; SLO targets and business-specific conditions are promises Watchdog has no way of knowing. If you understand that alert design is done with monitors, and Watchdog is placed as an auxiliary line that catches the unexpected outside that net, your expectations will not go wrong.