Skip to main content
Every Resolve problem sits at one stage of the path from alert to fix. Find the stage from the symptom below, then work through its cause, check and fix.

​
Find the stage

Two quick checks rule out most problems before you dig in:
  • Resolve → Integrations shows a readiness badge per platform. Anything other than Ready points at delivery. See readiness badges.
  • The header of Resolve → Investigation shows On duty or Paused. Paused means Pulse still groups alerts and still files incidents as Open, but CloudThinker doesn’t triage or investigate them on its own. See What starts an investigation.

​
Alerts not arriving

A connection that shows as healthy doesn’t prove alerts reach Resolve. A platform is a working source only once at least one signal path delivers.
Cause: the monitoring tool never sent, or sent to the wrong URL. Check: the delivery log in your monitoring tool, and the platform’s source row on Resolve → Integrations. If the tool’s log shows 401 or 403, the secret or URL is wrong. Fix: copy the webhook URL from the platform’s Signals to Resolve section again, paste it into the tool, and fire a test alert. If you no longer have the secret, choose Regenerate credentials from the webhook’s … menu and update the tool with the new URL and secret. Then open Resolve → Pulse and pick the All lane. Lanes are filters that choose which clusters you see, see Pulse.
Cause: the platform needs an account connected first, there’s no signal path yet, or an enabled outcome under What Resolve can do has no target. Webhook-only platforms, such as Amazon Web Services for CloudWatch alarms, never show Needs connection. Slack, Teams and Google Chat show Needs setup right after you connect, because Post incident updates is on by default with no channel. Fix: connect the account in the platform’s Connection section, click Add signal, or pick a target for the outcome marked Needs setup (or switch it off). Read readiness lists every badge and what to do about it.
Cause: a connection is unhealthy, or one signal path fails while others work. Check: open the platform and read each source row’s hint. Fix: follow the hint. For AWS polling, check the AWS connection and its permissions. See Read readiness for what each badge means.
Cause: an HTTP success only proves delivery. Pulse can still drop the event as noise: an exact repeat (same title, severity and resource, with an event timestamp in the same minute as an event seen in the last hour), an event past Pulse’s noise limit of 100 per minute from one source, or a match for a snooze. The noise limit always lets Critical and High events through. Check: the All lane, and any snooze on that source or resource. Fix: send a test alert with a different title, or click Unsnooze. See noise suppression.
Cause: the webhook’s hourly rate limit. Each webhook accepts 1,000 requests an hour by default. Events over it still get a success response, then are dropped before Pulse, whatever their severity. This is separate from Pulse’s noise limit. Check: drops are silent, so compare counts. Set the Resolve → Pulse time window to Last 1 hour and read the raw events count in the header. If it’s lower than what the sender reports sending in that hour, events were dropped. Fix: open the webhook’s … menu under Resolve → Integrations, choose Edit, and raise Rate limit (requests per hour), up to 10,000, or 0 for no limit.
Cause: one of three things. The source got more than 10 times its hourly rate limit, 10 failed authentication attempts arrived within 15 minutes (common right after a secret is rotated), or CloudThinker was briefly busy. Check: whether 401 or 403 responses came before the 429 in the tool’s delivery log. Fix: for an auth lockout, put the current secret and URL in the tool, then wait for the 15-minute window to clear. For the rate limit, raise Rate limit (requests per hour). Otherwise retry after the Retry-After header. See the custom source Responses table.
Cause: the channel isn’t on the watch list. Fix: on the Slack or Teams platform under Resolve → Integrations, add the channel in Listen for incidents.

​
Clusters not forming

A cluster is a group of related signals that Pulse treats as one problem. Every signal that survives noise suppression lands in a cluster, even a cluster of one. A new signal joins a recent open cluster when it shares a resource ID or a title with a signal there, or failing that, the same Service. How signals join a cluster has the full rule.
Cause: the alerts carry no resource ID, or a different one each time, so Pulse can’t tell they’re the same fault. A shared title doesn’t join two alerts whose resource IDs differ, and alerts with no Service (or unknown) can’t join by service. Check: in Resolve → Pulse, open each signal in the cluster and expand Raw payload to compare their resource IDs. Fix: for a custom source, open the source’s … menu, choose Edit, and set Resource ID Path to a stable ID in the payload, like alert.resource.id. The Resource field in setup is only a display name and doesn’t affect grouping. To join different alerts about one service, also map Service Path to a single service name.
Cause: the webhook has Send directly to CloudThinker on, which skips Pulse filtering and grouping. Check: open the webhook under Resolve → Integrations. Fix: turn it off unless the source is low volume and every event matters.
Cause: a custom source’s Incident title mapping points at the wrong field. Fix: edit the webhook, send a fresh payload, and pick the title field again.
Cause: the cluster is routed, which means an open incident already holds it. A matching signal joins that cluster and updates the incident instead of starting a second investigation. Check: look for the cluster in the Routed lane. Fix: work it from the incident. See cluster lifecycle.

​
Investigation not starting

Cause: On duty is paused. Pulse keeps detecting and grouping alerts and still files incidents as Open, but CloudThinker doesn’t triage or investigate them on its own. Check: the header of Resolve → Investigation. Fix: turn On duty back on, which changes what happens to new alerts — incidents filed while paused are not started retroactively. To start one now, click Investigate on the incident, or click Escalate and Send to triage on a cluster in Resolve → Pulse.
Cause: the incident has no investigation yet. Fix: select it in Resolve → Investigation and click Investigate (Admins only).
Cause: that webhook has Auto-investigate off, or Only from a minimum severity is set above the alert’s severity. Lower-severity alerts still group into clusters but don’t start triage on their own. Fix: open the webhook under Resolve → Integrations and adjust either option. The full rules are in What starts an investigation.
Cause: classification runs after a signal joins its cluster. It judged the signals Not actionable, so the cluster was never sent to triage. The signals aren’t suppressed: the cluster is there in the All lane. See noise suppression. Fix: if you need it handled, open the cluster on Resolve → Pulse and click Escalate in the action bar of its detail panel, then Send to triage. Or use Attach to incident… to link it to an incident you pick.
Check each cause in turn:

​
Investigation stuck

Click Watch live on the incident to see each check CloudThinker runs as it runs. If the timeline is moving, the investigation isn’t stuck.
Cause: CloudThinker wants to run a command that needs a person’s decision, so the run stops until someone answers. Check: the Action requires approval banner on the incident, or the Awaiting my approval filter on Resolve → Investigation. Fix: click Go to conversation and click Approve or Decline there. A declined action shows as Rejected in Execution history.
Cause: CloudThinker is waiting for information, access or a decision. The incident sits in the Needs your decision group on Resolve → Investigation until someone supplies it. Its status badge can read On Hold. Fix: open More actions → Open AI Conversation and answer what CloudThinker asked for.
Cause: the session hit an error, or stopped responding and was marked failed. The incident shows Analysis Failed with the error message. Fix: fix what the message names, such as an unhealthy connection, then click Retry Analysis. If the message is vague or the retry fails the same way, see Get help.
Cause: CloudThinker couldn’t read enough of your systems to back a root cause. Fix: add the missing connection, add context in the conversation, and investigate again. See evidence labels.

​
Runbook not running

A runbook is a step-by-step fix procedure that Resolve reads from Confluence, GitHub, GitLab or a manual upload. Each change-making command carries an effect (Allow, Require Approval, or Deny). Commands from Confluence, GitHub and GitLab always Require Approval. Only uploads can carry other effects, see Control command effects. Open Resolve → Runbooks → Execution history to see what happened to each run.
Cause: Resolve hasn’t searched your runbooks during an investigation yet, or no source is connected. Check: the Runbook sources tab. Fix: add a source. For Confluence, GitHub or GitLab, make sure the connection behind it can read the space or repository.
Cause: Require Approval is the default. Every change-making command from Confluence, GitHub or GitLab waits for a person, and so does any upload command whose effect nobody changed. Fix: approve it in the conversation. For an upload, you can change the command’s effect where your workspace shows Policies on Resolve → Settings. See Control command effects.
Cause: its effect is Deny, so Resolve can’t execute it. Only uploaded runbooks can carry Deny: commands from Confluence, GitHub and GitLab always Require Approval. Check: the Policy column in Execution history reads Denied. Fix: where your workspace shows Policies on Resolve → Settings, change the command’s effect to Require Approval or Allow in the upload’s policy. Otherwise, contact support. See Control command effects.

​
No updates in Slack or Teams

Cause: Live progress updates is off, or the incident has no active response (no Slack war room, Incident Room, Teams incident channel or Google Chat incident space attached). Check: the switch under Resolve → Settings → Behaviour, and whether the incident has a war room or Incident Room. Fix: turn the switch on, or attach a response, see On-call. Updates are always on the incident’s Investigation timeline. See Choose where progress appears.

​
Get help

Still stuck? Email support@cloudthinker.io with your workspace name, the incident ID (the id= value in the incident’s URL on Resolve → Investigation), the source name, the approximate alert time in UTC, the stage from Find the stage, and any error message shown on the incident.

Connect Pulse sources

Set up signal paths and read readiness badges.

Signal clusters

Understand grouping, suppression and cluster actions.

Investigation and RCA

Read verdicts, outcomes and evidence labels.

Runbooks

Add sources and control command effects.