Skip to main content
In about 10 minutes you create an alert endpoint, send it a test alert with curl, and follow that alert from Pulse to an incident and its root-cause analysis (RCA). You need no monitoring tool for this: a Custom source accepts any JSON you POST to it.

​
Prerequisites

  • The workspace Admin role. Developers and Viewers can see Resolve → Integrations but can’t add a signal. See Roles.
  • A terminal with curl.
  • Optional, for a meaningful RCA: at least one cloud or observability connection, so CloudThinker has something to investigate.

​
Create an alert endpoint

1

Open Resolve

Click Resolve in the sidebar. On a workspace with no source yet, you see Connect your first alert source. Click Skip for now. The wizard behind Connect a source asks you to type field paths, while the Custom source on Integrations captures your test payload so you can click the fields instead.
2

Add a Custom source

Go to Resolve → Integrations and select Custom source. In its panel, under Signals to Resolve, click Add signal.
Resolve Integrations page with platforms grouped by readiness and a search field

Resolve Integrations: platforms grouped by readiness, Needs attention first

3

Name it

Enter a Source name, for example quickstart-test, and click Create endpoint.Success state: the dialog shows a Webhook URL and a Secret Key, then says Waiting for the first payload.
4

Copy the URL and Secret Key

Copy both into a scratch file. The Secret Key is shown only here. If you lose it, see Troubleshooting.

​
Send a test alert

Keep the dialog open and run this from your terminal. Replace the two placeholders with the values you copied.
Success state: curl returns a 2xx status with a JSON body that includes "success": true. The dialog checks for the payload on its own and switches to Payload received. If it doesn’t, click Check again next to the waiting message. severity accepts critical, high, medium, low, or info, in any letter case, so Critical works too. Any other value lands as medium unless you add a severity mapping.
1

Map the fields

When the dialog shows Payload received, click Map the fields. For each target, click the matching field in the captured JSON:Click Save mapping.
2

Send the alert twice more, a minute apart

Run the curl command again, wait at least one minute, and run it a third time. The repeats join the first signal’s cluster instead of creating new work, because they share a title and a service. The payload has no resource_id, so title and service are what group them here. Clusters has the full rule.Each send that survives suppression becomes a signal, including the first one. The payload has no top-level timestamp field, so Pulse uses the time it received each send. An identical send in the same minute as an earlier one is dropped as a duplicate, which is why you wait. Expect two or three signals, depending on whether the first two sends landed in the same minute.

​
Watch Pulse cluster it

Pulse is Resolve’s detection layer. A signal is an event that survived noise suppression, and a cluster is a group of related signals that Pulse treats as one problem.
1

Open Pulse

Go to Resolve → Pulse.Success state: a cluster titled Checkout API 5xx rate above 5% with at least two signals, in the Active lane. If you see it in Forming with one signal, the repeats were too close together: wait a minute and send again.Already in Routed? On duty is on in a new workspace, so triage picked the cluster up on its own. Skip to Open the investigation.
2

Hand it to triage

Click the cluster, then Escalate → Send to triage. CloudThinker reads the cluster and matches it to an open incident, opens a new one, or decides it needs no incident.Success state: triage runs and settles the cluster. It moves to the Routed lane once triage links it to an open incident. If triage decides the cluster needs no incident, it stays in Active — see the note below.
For a made-up alert, both triage outcomes are normal. A test alert about a service CloudThinker can’t find in your connections may be judged as needing no action, so no incident opens and the cluster doesn’t move to Routed. That isn’t a mistake on your side: log the incident by hand in the next step. To make an incident more likely, replace checkout-api with a real service name from a connected account.

​
Open the investigation and root cause

1

Find the incident

Go to Resolve → Investigation. If triage opened an incident, it’s in the queue, under AI is handling while RCA runs. The row reads Investigating until the result is ready.No incident? Click Log Incident. Enter the alert title in What’s happening?, set Severity to Critical, and save. A logged incident starts its investigation as soon as you save, even while On duty is Paused. See Log an incident for the other fields.
2

Start RCA if it hasn't started

RCA starts on its own when triage opens an incident from Pulse, and a logged incident starts it as soon as you save. If the incident sits in Not started, open it and click Investigate. What starts an investigation has the full rules.
3

Read the result

Open the incident. CloudThinker shows its verdict, confidence, the evidence it read, a timeline, and remediation suggestions.Success state: the incident leaves AI is handling. With a connection that covers the alert, it lands in Needs your decision and the row usually reads Cause found. With no connections, expect one of two results:
  • It lands in Needs your decision with Investigation complete, and the result says CloudThinker couldn’t verify the cause.
  • Its status becomes Not Found, because the evidence didn’t support a root cause. A Not Found incident drops out of the queue, so copy the incident’s URL from your browser before you leave the page. See Investigation outcomes.
A result without a verified cause is the honest answer for a made-up alert. Connect the system the alert is about and the same flow produces a real root cause.

​
Clean up

The test source keeps accepting alerts until you remove it.
  1. Close the test incident so it doesn’t stay in your queue. Open it from Resolve → Investigation, click the status badge in the incident header, pick False Alarm, and click Change Status.
  2. In Resolve → Pulse, open the test cluster and click Resolve. The button shows once no open incident holds the cluster. Left alone, the cluster closes after 12 hours with no new signal.
  3. Go to Resolve → Integrations → Custom source, open the quickstart-test row’s ⋯ menu, and click Delete.

​
Troubleshooting

Check the status curl returned, then click Check again.If the dialog says an event arrived but no field could be read from its body, the send was accepted and its fields still couldn’t be mapped. Send the sample payload above again, then click Check again.
It isn’t shown again. On the Custom source card, open the source row’s ⋯ menu and click Regenerate credentials. That replaces both the Webhook URL and the Secret Key, and the old pair stops working at once, so update the URL and the key in anything that already sends to it.
Switch to the All lane and widen the time window. Then check the funnel at the top of Resolve → Pulse: if the raw event count went up but no cluster appeared, suppression dropped the event, most often as a duplicate sent in the same minute. Change the title and send again.
Escalate only shows on a Forming or Active cluster that isn’t routed yet. If the cluster is already in Routed, triage has it: open the incident from Resolve → Investigation.

​
Next steps

Your own tools: Connect alert sources matches the tool that already sends your alerts to a webhook, a polling source, or a chat channel. Walkthrough: see this same path on a real production incident in Investigate a checkout incident end to end.

Connect a real source

Point Datadog, Grafana, PagerDuty, or CloudWatch alerts at Resolve, and watch the Slack channels where people report incidents.

Read an investigation

What the verdict, confidence, and remediation queue mean.

Set up On-call

Bring responders into an Incident Room when an incident needs people.

Custom source reference

Field paths, authentication, and changing the mapping later.