Skip to main content
Pulse is the detection layer of Resolve, CloudThinker’s incident response module. It takes every alert your tools send, drops the noise, groups what’s left into clusters, and passes only the actionable ones on to triage, so one outage shows up as one item instead of hundreds of pages.

How it works

A raw event is one notification from a source, such as a CloudWatch alarm or a Datadog monitor. A signal is an event that survived noise suppression. A cluster is a group of related signals that Pulse treats as one problem.
A raw event passes suppression, joins a cluster, and is classified; a cluster with an actionable signal goes to Resolve triage and becomes an incident.A raw event passes suppression, joins a cluster, and is classified; a cluster with an actionable signal goes to Resolve triage and becomes an incident.

Pulse drops noise and groups signals into clusters; only a cluster with an actionable signal reaches triage.

  1. Ingest. Events arrive from webhooks, polled AWS services, and Slack or Microsoft Teams channels you choose. Webhooks arrive as they’re sent. Polled AWS services arrive on a schedule; Connect Pulse sources lists the intervals.
  2. Suppress. Four checks run in order, and the first match drops the event. See noise suppression.
  3. Cluster. Pulse joins a signal to a recent open cluster that has a signal with the same resource ID or title, or failing that, the same service. How signals join a cluster has the full rule.
  4. Classify. After a signal joins its cluster, CloudThinker classifies that signal: a category (compute, network, security, deploy, communication, cost or data, the same values as the category filter), a severity and whether it’s actionable.
  5. Triage. A cluster that holds an actionable signal goes to triage. CloudThinker matches it to an open incident, reopens a closed incident when the same fault comes back, or opens a new one.
Pulse itself only ingests, suppresses, and groups. Everything from triage onward belongs to Resolve. Pulse keeps detecting and grouping alerts whether the On duty switch in the Resolve → Investigation header is on or Paused. While it’s Paused, an actionable cluster is still filed as an incident with status Open, but CloudThinker doesn’t triage or investigate it on its own. Send to triage still runs when a person clicks it. What starts an investigation has the full rules.

Work from the Pulse page

Open Resolve → Pulse. The header shows the live funnel from raw events to clusters and a time window selector (Last 1 hour to Last 30 days). The window applies to every lane, Needs you included: a cluster shows only if it has a signal inside the window, so widen it to find an older cluster nobody handled. A row of lanes picks which clusters you see: A critical or high cluster is in Needs you when either is true:
  • It’s in Forming status, nobody has acknowledged or claimed it, and no open incident holds it.
  • Its triage failed and waits for Retry.
Lanes overlap. A routed cluster also shows in Active or Forming by its status, and a cluster that’s in Needs you because nobody has picked it up also shows in Forming. One there because its triage failed can be Active instead. Narrow any lane with the severity, source and category filters, or with Search signals…. Click a cluster to open its detail panel, where you can Acknowledge, assign it, Escalate, Attach to incident… or Resolve it. Clusters explains each action. To check a new source works, follow Send a test alert on the setup page.

When Pulse is empty or quiet

Next steps

Connect Pulse sources

Send your first alerts into Pulse and confirm they arrive.

Work with clusters

Learn the cluster lifecycle, suppression and every cluster action.

Pulse Analytics

Measure how much noise Pulse removes and how fast clusters close.

Root cause analysis

See what happens after triage opens an incident.