Skip to main content
By the end of this tutorial, CloudThinker will have traced one real symptom in your Kubernetes cluster through your cloud account and your recent code changes, named a root cause with evidence, and proposed a fix that waits for your approval. Allow about 15 minutes.
What you’ll need: a workspace (the quickstart creates one) with three connections showing Connected: Kubernetes, a cloud account such as AWS, Google Cloud, or Azure, and a code host such as GitHub or GitLab. Read-only access is enough for every step.Only have Kubernetes connected? Skip the cloud and code steps and use the cluster-only prompt in the root-cause step. Not ready to connect production? Connect a staging cluster with a read-only kubeconfig (Kubernetes steps), drop in the production namespace from the first prompt, and follow any pod it lists.
Every prompt below is plain language. For the full prompt syntax, see Commands. Each message spends credits, and the root-cause step spends more because it runs several subagents.

​
Walk through the investigation

The prompts below use a service called checkout in the production namespace. Swap in a service of yours that has restarted, run slowly, or thrown errors recently. A real symptom gives a real answer.
1

Check your connections

Go to More → Workspace settings → Connections and confirm your Kubernetes, cloud, and code connections are listed.Success state: each one shows Connected. If one shows Connection error, fix it from its connection page before you continue, or CloudThinker will skip that layer.
2

Switch this chat to Manual

Click New chat in the sidebar (or use the chat box on Home). Before you send anything, click the approval control in the bottom row of the prompt box, just left of the send button. Under Approval for this chat, choose Manual. Every write in this chat now waits for your Approve.Success state: the approval control shows Manual.
3

Start with the symptom

In the same chat, send:
CloudThinker queries the cluster and replies with a list of pods. Look for termination reasons such as OOMKilled or CrashLoopBackOff, and note which nodes they share.Success state: the answer names pods and nodes from your own cluster, not generic examples.
4

Bring in the cloud layer

Build on the same conversation. You don’t need to repeat the pod names:
CloudThinker maps the Kubernetes nodes to their cloud instances and pulls metrics and events for them. This works when the nodes run in the cloud account you connected, such as an EKS, GKE, or AKS cluster. If they don’t, such as on-premises nodes, CloudThinker can’t map them to instances. Skip to the code step.Success state: the reply ties at least one node to a specific instance in your cloud account, with numbers for the time window you asked about.
5

Check what changed in code

Swap in your repository as owner/name, as above. That’s the reliable route. With several code connections, also type # and pick the right one. For a monorepo, add the path, such as under services/checkout.CloudThinker reads the repository through your code connection and lists the changes with author, time, and a one-line summary of each.Success state: you see pull requests or commits you recognize, each with a timestamp you can line up against the first restart.
6

Ask for one root cause

Now ask CloudThinker to put the three layers together:
On the Kubernetes-only path, send this instead: Using the pod events, logs, resource limits, and recent rollouts, give me the most likely root cause, the evidence for it, and anything that rules out the alternatives.For a request like this, CloudThinker often spawns subagents to check each layer in parallel. You’ll see Spawn Subagents in the chat and can follow each one in the Agents tab of the side panel.Success state: one answer that names a cause (for example, a memory limit lowered in a recent merge, followed by OOMKilled restarts on the same pods), cites the evidence from each layer, and says what it ruled out.
7

Review the proposed fix

CloudThinker describes the change, such as a patch to the deployment or a pull request that restores the limit. In Manual, any write waits for you on an action card. In the web app it shows Approve, Approve and draft rule, and Decline. Google Chat shows its own buttons: Approve, Approve with reason, and Reject. Slack and Microsoft Teams don’t have approval buttons; they post a View in CloudThinker link, and you decide in the web app.What you see depends on the connection:
  • Read-only role, Allow writes on: the card appears. If you approve, your provider rejects the write and the chat shows the error. Nothing changes.
  • Allow writes off: no card appears. CloudThinker refuses the write before calling the provider.
To let a fix run, widen the connection’s permissions and turn on Allow writes in its detail panel. See How access works.
Approving runs the change against your real systems. On a production cluster, click Decline for now. Ask CloudThinker for the change as a diff you can apply through your normal review, or, if your code connection has write access, to open a pull request.
Success state: you’ve seen the exact change and made a decision. If you approved, the conversation shows the result. If you declined, nothing changed.
8

Write it up

Success state: a write-up you could paste into a ticket or postmortem without editing the facts. It lives in this chat. To send it to a teammate, see Sharing. With Jira connected, you can ask CloudThinker to file it as a Jira issue. That’s a write, so it waits for your approval.

​
You’re done when…

  • CloudThinker named pods, nodes, instances, and commits from your own environment
  • One answer named a single root cause with evidence (from all three layers, or from the cluster alone on the Kubernetes-only path)
  • You saw a proposed change and chose to approve or decline it
  • You have a written summary of the investigation

​
Troubleshooting

The connection is missing, in error, or lacks read access. Open More → Workspace settings → Connections, check the status, and follow the troubleshooting section on that connection’s page.
Name the target in the prompt (the namespace, region, or repository) or type # and pick the connection. With several clusters or accounts, CloudThinker may have looked at a different one.
Widen the window (“in the last 7 days”) or start from a different symptom, such as slow responses or a spike in 5xx errors. The rest of the steps work the same way.
First check the approval control in the prompt box still shows Manual. It applies to one chat only, so a new chat starts on the Chat run type’s mode (the workspace mode, unless an admin set an override for Chat on Approval mode). If it shows an Auto mode, your workspace’s Approvals allowed that action to run without asking. Review your Approval mode and rules before running fixes on production.

​
Next steps

Resolve quickstart

Have CloudThinker investigate incidents like this one as soon as an alert fires

Approvals

Decide which fixes run on their own and which wait for you

Custom skills

Save this investigation as a procedure CloudThinker runs your way

Glossary

Look up any term from this tutorial