> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Resolve Troubleshooting

> Find and fix the stage where Resolve stopped: alerts not arriving, clusters not forming, investigations stuck, or runbooks not running.

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

| Symptom | Stage | Go to |
| - | - | - |
| **Resolve → Pulse** shows nothing from a source | Delivery | [Alerts not arriving](#alerts-not-arriving) |
| Alerts arrive, but each one is its own cluster, or none appears | Grouping | [Clusters not forming](#clusters-not-forming) |
| Clusters appear, but no incident is created or no investigation starts | Triage | [Investigation not starting](#investigation-not-starting) |
| The incident sits in **AI is handling**, or in **Needs your decision** as **On Hold**, **Investigation stopped**, or waiting on an approval. **Cause found** there is a finished result, not a stuck one. | Investigation | [Investigation stuck](#investigation-stuck) |
| A fix is proposed but never applied | Remediation | [Runbook not running](#runbook-not-running) |
| An investigation ran, but no updates show in Slack or Teams | Reporting | [No updates in Slack or Teams](#no-updates-in-slack-or-teams) |

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](https://docs.cloudthinker.io/guide/incident/integrations.md#read-readiness).
* 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](https://docs.cloudthinker.io/guide/incident/settings.md#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.

> **Pulse shows No signals yet**
>
> **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](https://docs.cloudthinker.io/guide/pulse/overview.md#work-from-the-pulse-page).

> **The platform shows Needs connection or Needs setup**
>
> **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](https://docs.cloudthinker.io/guide/incident/integrations.md#read-readiness) lists every badge and what to do about it.

> **The platform shows Needs attention or Partially ready**
>
> **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](https://docs.cloudthinker.io/guide/connections/aws.md) and its permissions. See [Read readiness](https://docs.cloudthinker.io/guide/incident/integrations.md#read-readiness) for what each badge means.

> **The tool reports success, but nothing shows in Pulse**
>
> **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](https://docs.cloudthinker.io/guide/pulse/clusters.md#noise-suppression).

> **Alerts stop arriving during a burst**
>
> **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.

> **The tool reports 429**
>
> **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](https://docs.cloudthinker.io/guide/incident/webhook-integrations/custom-source.md#responses).

> **Slack or Teams messages aren't picked up**
>
> **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](https://docs.cloudthinker.io/guide/pulse/clusters.md#how-signals-join-a-cluster) has the full rule.

> **Every alert opens its own cluster**
>
> **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](https://docs.cloudthinker.io/guide/incident/webhook-integrations/custom-source.md), 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.

> **Alerts arrive but no cluster appears**
>
> **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.

> **Clusters have no useful title**
>
> **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.

> **A new alert didn't start a new investigation**
>
> **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](https://docs.cloudthinker.io/guide/pulse/clusters.md#cluster-lifecycle).

## Investigation not starting

> **Alerts show in Pulse, but nothing is triaged or investigated**
>
> **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**.

> **Incidents wait in Not started**
>
> **Cause:** the incident has no investigation yet. **Fix:** select it in **Resolve → Investigation** and click **Investigate** (Admins only).

> **On duty is on, but one source never triggers an investigation**
>
> **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](https://docs.cloudthinker.io/guide/incident/settings.md#what-starts-an-investigation).

> **A cluster never became an incident**
>
> **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](https://docs.cloudthinker.io/guide/pulse/clusters.md#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.

> **There's no Investigate button**
>
> Check each cause in turn:
>
> | Cause | How to tell | Fix |
> | - | - | - |
> | An investigation is already running | The incident shows **AI is handling** and a **Watch live** button | Wait for it, or follow it with **Watch live** |
> | The incident is part of a correlated group | A **View Parent Analysis** link shows on the incident | Click it to open the incident that owns the investigation |
> | The incident was already investigated | Its analysis is shown instead of an empty state | Read the verdict, or use **Retry Analysis** if it failed |
> | You don't have the workspace Admin role | Your role shows in the workspace's [members list](https://docs.cloudthinker.io/guide/workspace-users.md), which every role can view | Ask an Admin to investigate or change your role, see [Roles](https://docs.cloudthinker.io/guide/security/roles.md) |

## 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.

> **Action requires approval**
>
> **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**.

> **Needs your decision**
>
> **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.

> **Analysis Failed**
>
> **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](#get-help).

> **The verdict is Cause unproven or Not Found**
>
> **Cause:** CloudThinker couldn't read enough of your systems to back a root cause. **Fix:** add the missing [connection](https://docs.cloudthinker.io/guide/connections/overview.md), add context in the conversation, and investigate again. See [evidence labels](https://docs.cloudthinker.io/guide/incident/root-cause-analysis.md#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](https://docs.cloudthinker.io/guide/incident/runbooks.md#control-command-effects). Open **Resolve → Runbooks → Execution history** to see what happened to each run.

| Column | Values | What to do |
| - | - | - |
| **Policy** | **Auto Execute**, **Requires Approval**, **Denied**, **Per Command** | **Denied** never runs. **Per Command** is an uploaded runbook, checked command by command. |
| **Approval** | **Pending**, **Approved**, **Rejected** | **Pending** waits for a person. Approve it in the investigation conversation. |
| **Status** | Empty, **Not Started**, **Completed**, **Failed** | Empty means nothing ran: the action waits for a person, was declined, or was denied. **Failed**: read the run's result before retrying or resolving the incident. |

> **Execution history says No runbook executions yet**
>
> **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](https://docs.cloudthinker.io/guide/connections/overview.md) behind it can read the space or repository.

> **A command waits even though nobody set it to Require Approval**
>
> **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](https://docs.cloudthinker.io/guide/incident/runbooks.md#control-command-effects).

> **The command was blocked**
>
> **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](#get-help). See [Control command effects](https://docs.cloudthinker.io/guide/incident/runbooks.md#control-command-effects).

## No updates in Slack or Teams

> **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](https://docs.cloudthinker.io/guide/incident/oncall.md). Updates are always on the incident's **Investigation timeline**. See [Choose where progress appears](https://docs.cloudthinker.io/guide/incident/settings.md#choose-where-progress-appears).

## Get help

Still stuck? Email [support@cloudthinker.io](mailto: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](#find-the-stage), and any error message shown on the incident.

## Related

> **[Connect Pulse sources](https://docs.cloudthinker.io/guide/pulse/setup.md)**
>
> Set up signal paths and read readiness badges.

> **[Signal clusters](https://docs.cloudthinker.io/guide/pulse/clusters.md)**
>
> Understand grouping, suppression and cluster actions.

> **[Investigation and RCA](https://docs.cloudthinker.io/guide/incident/root-cause-analysis.md)**
>
> Read verdicts, outcomes and evidence labels.

> **[Runbooks](https://docs.cloudthinker.io/guide/incident/runbooks.md)**
>
> Add sources and control command effects.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.