Skip to main content
Incident memory is the set of notes CloudThinker writes at the end of a root cause investigation and reads at the start of the next one. When the same service fails the same way again, CloudThinker starts from what your team already learned instead of from zero.

​
Prerequisites

  • Resolve receiving alerts from at least one source. See Connect Pulse sources.
  • Nothing to switch on, and no workspace switch to turn it off. Every investigation that reaches a disposition writes memory, whether On duty started it or an Admin clicked Investigate. All roles can read the investigation results. See Roles.

​
What CloudThinker records

CloudThinker writes memory itself. You don’t fill in a form, and not every incident produces an entry. Each entry is one of three kinds: CloudThinker writes or updates a recollection after any run where it actually investigated and reached a disposition (it saved an assessment, a severity and a close decision). It writes nothing for a plain question, an aborted run, or a run that never reached a disposition. When an incident reopens, CloudThinker updates that incident’s existing recollection instead of adding a second one. Every recollection follows the same five-line shape. This example shows what one looks like:
CloudThinker keeps observed facts, inferences and unknown history separate. A field it can’t support says unknown rather than a guess.

​
How recall works

When a new investigation starts, CloudThinker reads memory before it forms any hypothesis:
  1. It loads the 20 most recently updated entries in the workspace, across all three kinds, without filtering by service. In a busier workspace, an older recollection is found only if CloudThinker looks beyond those 20, through the full list of the workspace’s recollections.
  2. It looks for a matching recollection: the same symptom on the same service or component.
  3. If the matching incident was resolved before, it runs the one cheap check that recollection recorded to prove the fix.
    • Check passes: the old fix still holds. CloudThinker reads the current evidence to decide the disposition. A repeated report of the same episode isn’t counted as a new occurrence.
    • Check fails: CloudThinker investigates the current fault on its own terms. It doesn’t assume the old cause came back.
  4. It treats every recalled entry as a lead, not as evidence. The verdict still rests on data from your systems, and memory never upgrades an Inferred cause to Verified.
Keep Service and Resource ID Path names the same on every source, so recall can match a new alert to the old incident.
Incident memory isn’t listed in More → Workspace settings → Memory (under Agent Configuration), which shows workspace memory items. To see what CloudThinker checked, click Watch live while it runs, or open More actions → Open AI Conversation afterwards. When a past fix was rechecked, the conversation shows the Verify-with: check CloudThinker ran. There’s no separate step that lists the recalled entries.

​
Confirm a fix held

A recollection that records an applied fix starts as Unverified. A follow-up check turns it into Verified or Failed, which decides whether later investigations trust it.
1

Open the investigation conversation

Go to Resolve → Investigation, select the incident, and open More actions → Open AI Conversation.
2

Enable the follow-up card

When CloudThinker applied a fix itself and recorded a Verify-with: check, it proposes a follow-up as a card in the conversation. The card shows when it runs and what it watches for. Enable and Dismiss need the workspace Admin role. Nothing is scheduled until an Admin clicks Enable. Other members see the card without buttons, with the note Only members who can create automations may enable this. Send the conversation link to an Admin, or ask for the check yourself (next step).No card appears for a fix your team applied by hand, and the card has no time picker. In either case, ask for the check yourself (next step).Success state: the card shows Scheduled, and the follow-up becomes an automation that runs at the proposed time.
3

Or ask for one yourself

If no card appeared, ask in the same conversation:
Name the time zone in the request so the run time isn’t ambiguous. Success state: the follow-up is listed under your automations with the time you asked for.
4

Read the result

When the follow-up runs, it reports the check result in the conversation and sets the recollection’s outcome.

​
Verification outcomes

You see an outcome only in the follow-up’s report in the conversation. No other screen shows it.

​
How memory stays accurate

There’s no screen for viewing, exporting, editing or deleting incident memory. Memory is kept per workspace and never shared with another workspace. For how CloudThinker stores and protects workspace data, see the security overview. If an entry is wrong or holds data that shouldn’t be there, email support@cloudthinker.io with your workspace name and the incident ID. CloudThinker maintains memory as it works:
  • When new evidence contradicts a sentence in a past recollection, CloudThinker edits that sentence and states the observation that corrects it.
  • An unsupported historical claim is marked unverified, not deleted. A different fault today doesn’t erase a supported older incident.
  • Two lessons that contradict each other are merged into one corrected lesson, or the obsolete one is deleted.
  • An outdated entry is edited in place rather than duplicated.
You help by letting investigations finish, settling each suggestion in the incident’s Remediation section (under the result on Resolve → Investigation) with Mark as Done or Dismiss and a note on what you actually did, and enabling follow-up checks. See Settle each remediation suggestion.

​
Troubleshooting

Cause: the earlier run never reached a disposition, so no recollection was written. Or the new incident has a different symptom, service or component. In a workspace with many incidents, the old recollection may also sit outside the 20 most recent entries, see How recall works. Check: open the earlier incident and confirm it shows a Current assessment and a closed outcome. Fix: let investigations run to a verdict. For a custom webhook, map Service and Resource ID Path (in the source’s edit view) so incidents name the component consistently. See custom source.
Cause: the earlier fix was never checked, so its recollection stayed Unverified. Fix: enable the follow-up card next time, or ask for a follow-up check in the conversation as shown above.
Cause: the card was never enabled. A proposed follow-up isn’t an automation until you enable it. Check: look for the follow-up under your automations. Fix: enable the card in the conversation, or ask CloudThinker to schedule the check.

​
Next steps

Investigation and RCA

Run an investigation and read its verdict.

Runbooks

Give Resolve approved procedures for applying fixes.

Workspace memory

See what agents remember across all conversations.