Skip to main content
Pulse analytics tells you whether your alert pipeline is doing useful work. In one tab you see how many raw events came in, how many Pulse held back as noise, how many reached an incident or were resolved, and which sources send the most volume. A few terms used on this page:
  • Raw event: one notification Pulse received, such as a single Datadog alert or CloudWatch alarm.
  • Signal: an event that survived noise suppression.
  • Suppressed event: an event Pulse judged as noise but kept so it can count it (Rate limit, Snooze and Verdict). Dropped duplicates aren’t kept.
  • Stored events: signals plus suppressed events.
  • Cluster: a group of related signals that Pulse treats as one problem.
  • Reached an outcome: a Signal whose Cluster was either linked to an incident or resolved. Correlation yield and the Clusters routed column both count this (includes auto-closed, see Auto-resolved Clusters).
See Clusters for the full lifecycle.

​
Open Pulse analysis

1

Go to Insights

In the sidebar, open Resolve → Insights, under Analytics. The workspace Admin, Developer, and Viewer roles can all open it.
2

Pick the Pulse tab

Click the Pulse analysis tab. The other tabs (Overview, Accuracy & trust, Runbook analytics) are covered in Resolve insights.
3

Set the time window

Use the window selector at the top right. Options run from Last 1 hour to Last 30 days. The default is Last 7 days. Each card filters on a different time, listed in the Window filters on column below. A Cluster that formed 8 days ago and resolved yesterday is missing from Cluster MTTR in Last 7 days, but its Signals from the last 7 days still count in Correlation yield.Success state: four metric cards appear, followed by the Top noisy sources table. If no events arrived in the window, the table reads “No signals ingested in this period”.
Numbers are computed when the tab loads. Reload to refresh. There is no export.

​
What each metric means

Because of dropped duplicates, Signals ingested is usually larger than the stored event count behind the other cards. Cluster MTTR is a median over Clusters. Mean time to resolve on the Overview tab is a mean over incidents. Expect them to differ.
Deliveries over a webhook’s rate limit (1,000 per hour by default) are dropped silently, still return 200, and appear nowhere on this tab. Resolve doesn’t show a dropped count. If alerts from a burst are missing, compare the number your tool sent that hour with Signals ingested, then raise the webhook’s limit or split the monitors. See Limits and responses.

​
Auto-resolved Clusters

A Cluster with no new Signal for 12 hours closes on its own and counts as resolved. That affects three numbers:
  • Correlation yield and Clusters routed count it as reaching an outcome, even if nobody looked at it. A high yield means alerts settled into Clusters that ended, not that every alert mattered. Read it next to the Routed lane on Resolve → Pulse, which shows only Clusters linked to an incident.
  • Cluster MTTR measures it to the auto-close time, not to its last Signal.
An untouched Cluster takes at least 12 hours to resolve, so it adds 12 hours or more to Cluster MTTR. If most Clusters close on their own, the median mostly reflects that timer. To make MTTR track real recovery, click Resolve on the Cluster panel when the problem ends. See Action reference.
Noise suppressed is not the same number as Noise reduced on the Overview tab. Overview measures raw events collapsing into incidents. Pulse analysis measures suppressed events over stored events. Compare each number only with itself over time.

​
Top noisy sources

The table ranks the 10 sources that sent the most events in the window. One integration can show up as several rows. A single AWS connection, for example, can produce a separate stream per account and region.

​
Read the results

Use the numbers to decide where to spend tuning time. There’s no benchmark for a healthy percentage, because it depends on your sources. Compare each number with its own trend week over week. Pulse suppresses events with four checks:
  • Dedup of repeat deliveries
  • A per-source rate limit
  • A Snooze someone set
  • Noise patterns it learned
Details for each are in Noise suppression. For example, a row reading webhook.datadog, Signals 4,800, Suppressed 92%, Clusters routed 1% says Datadog sends a lot of repeats and almost none of it leads anywhere. Open a few of its Signals on Resolve → Pulse to find the monitors behind them, then raise their thresholds or turn them off in Datadog. Treat these as pointers, not verdicts. Look at the actual clusters and signals before you change a source or a snooze.

​
Troubleshooting

​
Next steps

Tune Clusters and suppression

Act on what the noisy-sources table shows.

Connect Pulse sources

Add or fix the sources feeding Pulse.

Resolve insights

See reliability, accuracy, and runbook results next to Pulse.

Investigation and RCA

Follow a routed Cluster into its investigation.