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.
| API endpoint | Datadog Monitors API, GET /api/v1/monitor?with_downtimes=false&group_states=alert. Returns the monitor list with state, priority, query, message, and last-triggered timestamp. |
| Metric basis | Monitor state machine: monitors whose current state is Alert (NOT Warn). The card excludes Warn because Alert is the actionable category. Warn lives on the broader Alerts Summary. |
| Aggregation window | Real-time, refreshed every 60 seconds. |
| Severity threshold | All priorities surfaced; the table sorts by priority (P1 first) then by last-triggered descending. |
| Alert pre-filtering | (1) Muted monitors and monitors in scheduled downtime excluded; (2) Test/synthetic-internal monitors excluded; (3) Monitors created in the last 60 minutes flagged “new monitor, may not be stable” so freshly-misconfigured thresholds are visually distinct. |
| Log Management gating | Some monitors are log-based; if Log Management is disabled, those monitors persist as No Data rather than Alert. The Logs API gating returns 400 No valid indexes; the engine logs once at INFO and skips log-based monitor evaluation. APM, infrastructure, and synthetic monitors continue to function. |
| Filtered hosts / services | All monitors in the connected Datadog account. To scope to a team, set the connector tag scope to team:your_team. |
| Time zone | Last-triggered timestamps in account timezone for chart axes; UTC for cross-connector arithmetic. |
| What this card is NOT | This is not the same as Active Incidents. Alerts can fire without an incident being declared; incidents can exist without active alerts. |
| Time window | RT (real-time, refreshed every 60 seconds) |
| Alert trigger | > 0, any monitor in Alert state surfaces here. |
| Roles | owner, engineering, operations |
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.| Priority | Monitor name | Triggered at | Value | Threshold | Owning team |
|---|---|---|---|---|---|
| P1 | Checkout p95 latency | 09:08 EST | 3,420 ms | 1,500 ms | checkout |
| P2 | Web error rate | 09:11 EST | 2.6% | 1.5% | web |
| P2 | DB connection pool above 85% | 09:09 EST | 91% | 85% | platform |
| P2 | Recommendations Apdex | 09:13 EST | 0.79 | 0.85 | personalisation |
| P3 | Container restart rate | 09:12 EST | 14/h | 10/h | platform |
| P3 | Log volume up | 08:45 EST | +38% | +30% | platform |
| P4 | Disk above 75% | 06:22 EST | 78% | 75% | platform |
- 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
| Card | Why pair it with Currently Triggered Monitors | What the combination tells you |
|---|---|---|
| Alerts Summary | The headline-number version of this card. | Use Alerts Summary for daily glance; this card for triage. |
| Active Incidents | The human-declared response state. | Many triggered monitors plus zero incidents equals “engineering has not decided this is real yet”; many triggered plus active incident equals coordinated response in progress. |
| Recently Flapped Monitors (24h) | The “noisy monitors” view. | If a monitor in this list also appears in flapped, it is likely a misconfigured threshold rather than a real problem. |
| Sustained Threshold Breaches | Monitors stuck in Alert state for over 30 minutes. | A monitor in this list AND in sustained-breach equals “stuck investigation, escalate”. |
| Monitors Without Notification Channel | The silent-failure view. | A P1 in this list that ALSO has no notification channel equals “the most expensive alert on the dashboard nobody knows about”. |
| Monitor Coverage by Service | The blind-spot view: services without alert coverage. | Triggered monitors say what is firing; coverage says what could fire but does not exist yet. |
| Operational Health Score | The composite engineering view. | Score below 70 with monitors triggered equals real cascade; score above 80 with monitors triggered equals noisy-monitor problem. |
| Top Alerting Services | Pattern view across the last week. | Same service repeatedly in this card and the trend equals chronic problem worth investing in. |
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:
| Reason | Direction | Why |
|---|---|---|
| Time zone | Last-triggered timestamps shift | Datadog UI displays in account timezone; Vortex IQ stores UTC. |
| API rate limits | Brief gaps | The Monitors API is rate-limited; on burst minutes a polled value may use cached data. |
| Log indexing latency | Log-based monitor count lower | Logs API gating returns 400 No valid indexes when Log Management is disabled; log-based monitors persist as No Data. |
| Monitor state cache | Up to 60 seconds | Monitor state refreshes once per minute. |
| Mute / downtime exclusion | Vortex IQ list shorter | Muted monitors and monitors in scheduled downtime are excluded from Vortex IQ; Datadog UI shows them with a mute icon. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
| Datadog Active Incidents | Monitors trigger before incidents are declared. | Monitor list populated plus zero incidents equals “engineering has not decided this is real yet”. |
google_analytics.ga_property_health | Independent measurement-side health peer. | Triggered monitors plus GA4 amber equals “site is broken AND analytics is broken simultaneously”. |
| PagerDuty triggered incidents | Should be 1:1 with Datadog priority:1 triggered monitors if the integration is configured. | A gap means the PagerDuty-Datadog integration is misconfigured; pages reach humans but Datadog does not know. |
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.