At a glance
The detail table for monitors currently in Alert state, showing each monitor’s name, priority, last-triggered timestamp, and the metric value that breached. Where Alerts Summary is the headline number, this card is the inspectable list. For a merchant, this is “what specifically is firing right now and how do I read it”. Use this card to triage; use Alerts Summary for the daily glance.
Calculation
Calculated automatically from your Datadog data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US apparel brand on Shopify with 47 Datadog monitors. Snapshot taken on 25 Apr 26 at 09:15 EST.
The dashboard headline reads “7 monitors triggered (1 P1, 3 P2, 2 P3, 1 P4)” with a P1 highlighted. Three things the merchant should read:
- The P1 is the only one that costs money right now. Checkout p95 at 3,420 ms means real shoppers are abandoning slow checkouts. The triage path: open p95 Response Time for the time-series, then Top Slow Endpoints to identify which checkout endpoint is the source.
- The three P2s are clustered around the same root cause. Web error rate, DB pool exhaustion, and recommendations Apdex all triggered between 09:09 and 09:13 EST. The temporal alignment suggests one cause: the DB pool exhaustion (09:09 EST first) is causing the web errors and recommendations slowness. One fix may resolve all three.
- The two P3s and one P4 are background noise during this incident. Container restarts and log volume are likely symptoms of the same DB pool issue (containers are restarting because health checks fail when DB queries time out). The disk warning is unrelated, an old, un-actioned alert. Engineering should ignore them while the P1+P2 cluster is being resolved.
- The detail table is the triage starting point. Headlines tell you “something is wrong”; this card tells you “what specifically and where”. Engineering should always pivot from Alerts Summary to this card within seconds.
- Alert clusters with temporal alignment usually share a root cause. Three P2s firing within 5 minutes of each other is almost always one underlying problem. Resist the urge to triage them as three separate problems; find the common cause.
- Background P3+P4 alerts are usually symptoms or noise. During a real incident, ignore them; address them only after the P1+P2 cluster is resolved. Triaging everything at once dilutes the response.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Datadog:Monitors → Triggered Monitors for the master list filtered to Alert state. Monitors → Manage Monitors for all monitors with state filters. Monitor Detail (any monitor) for the time-series, history, and notification settings of a specific monitor.Why our list may legitimately differ from Datadog’s UI:
Cross-connector reconciliation:
Known limitations / merchant FAQs
Why is this card a separate hero from Alerts Summary? Alerts Summary is the headline number (“7 monitors triggered”); this card is the inspectable list. Engineering on-call uses this card during triage; merchants use Alerts Summary for the daily glance. Both surface the same underlying API data but at different levels of detail. My team uses PagerDuty for paging. Why does this card matter? Because PagerDuty pages are downstream of Datadog monitors. A monitor in this list is a metric breach Datadog has detected; whether PagerDuty paged a human depends on the integration configuration. If you see triggered monitors here but no PagerDuty pages, your integration is filtering or routing differently than expected. The card is the source-of-truth list of monitors actively in Alert state in Datadog. Why are P5 alerts shown here? They are not actionable. Same reason as Alerts Summary: some teams use P5 for “info” monitors that should be visible but never page. Showing them here lets engineering see the full state without filtering, while the priority sort keeps P1 at top. Datadog says monitors are triggered but customers are placing orders normally. The classic Datadog blind spot. Three causes: (1) The triggered monitors are on internal services (workers, batch, admin) that do not affect storefront; (2) The monitors have wrong thresholds (firing on transient noise that does not impact customers); (3) Real customer impact is masked by retries (shoppers retry slow checkouts and eventually succeed). Open the per-monitor detail to see what each is firing on; if the metric value is barely above threshold, the threshold is too tight. My Logs API returns 400 No valid indexes. Are log-based monitors counted? No. Log-based monitors cannot evaluate when Log Management is disabled and remain inNo Data state. They are excluded from this card. The Vortex IQ engine logs the gating event once at INFO and continues serving APM, infrastructure, and synthetic monitors normally.
Why do some triggered monitors not have a “Last triggered” timestamp?
Two cases: (1) The monitor evaluates on a “no data” condition and the data has been continuously absent for some time; the last-triggered timestamp is the start of the no-data window, which can be unhelpful; (2) The monitor was just created and has not yet finished its evaluation window. Datadog returns the timestamp when available; the card surfaces “n/a” otherwise.
Can I exclude muted monitors from this card?
Yes, that is the default. Monitors tagged muted:true or in scheduled downtime are excluded automatically. To include them (for an audit), use the unfiltered query in the Datadog Monitor UI directly.
My multi-team Datadog account has 200+ monitors from teams I do not own. Are those shown?
By default, all monitors in the account. To filter by team, set the connector’s tag scope to team:your_team_name in Vortex IQ Settings → Datadog → Tag scope. The card then only displays monitors tagged with your team. Most merchants want unfiltered because alerts from any team can affect shopper experience.
RUM and Synthetic monitors look different. Are they counted?
Yes. The Monitors API is product-agnostic; alerts from RUM, Synthetic, APM, infrastructure, and log-based monitors all count the same. The category is shown in the per-row detail in the Vortex IQ table.
Why does the alert volume fluctuate every minute?
Because monitors evaluate on a 1-minute schedule. Some monitors are flap-prone (their underlying metric oscillates around the threshold). To stabilise, increase the monitor’s evaluation_window (default 5 minutes; for noisy metrics use 15 minutes) so it requires sustained breach before firing. Use Recently Flapped Monitors to identify candidates.