Introducing CloudThinker SlackOps: The Future of Conversational Infrastructure Management

Fourteen browser tabs. Three terminal windows. Two Slack channels. One on-call engineer.

It's 2:47 AM when the PagerDuty alert fires. A latency spike in the payment service is cascading across checkout, and customers are starting to see timeouts. James, the SRE on call at a mid-size e-commerce company (a composite of the teams we work with), does what every on-call engineer does: he opens tabs.

CloudWatch for metrics. Grafana for dashboards. The AWS console for instance health. Datadog for traces. Kibana for logs. The deployment pipeline, to see if something shipped. The runbook wiki, which loads slowly and turns out to be six months out of date.

Then the Slack messages start. The support lead wants to know what's happening. The VP of Engineering wants an ETA. A developer on another team mentions they saw "something weird" earlier but didn't file a ticket.

The incident takes 47 minutes to resolve. When James reviews the timeline afterwards, only 8 of those minutes went on investigation and the fix. The other 39 went on switching context: jumping between tools, finding the right dashboard, lining up timestamps across systems, and explaining the situation in two channels while trying to fix it.

01Fixing

8 minutes

Finding the cause and applying the change.

02Switching

39 minutes

Opening tools, lining up timestamps, writing status into two channels.

That's the hidden cost of cloud operations. It isn't the incidents. It's the overhead of handling them across a fragmented set of tools, with a person acting as the glue.

---

Why ChatOps didn't fix this

Teams have been running operations from chat for a decade. The path most organizations followed looks like this:

01Traditional

Manual ops

Hand provisioning, reactive monitoring, people as the response plan.

02Cloud

Dashboards

Infrastructure as code and autoscaling, with a dashboard for every tool.

03ChatOps

Bots run commands

Scripts triggered from chat. Faster, but you still need to know which one.

04SlackOps

Agent investigates

Plain-language requests, evidence gathered across tools, actions gated by Auto Mode.

ChatOps was a real improvement. A bot that runs deploy checkout to prod from a channel is faster and more visible than a terminal on someone's laptop. It still stops short of the expensive part, for structural reasons:

• Commands assume you already know the answer. A ChatOps bot runs the script you name. At 2:47 AM the hard question is which script, and that depends on evidence the bot never looks at.
• Each tool keeps its own view. The Datadog bot answers about traces, the AWS bot about instances. Joining a latency spike to a database pool to a traffic surge is still a human job.
• Scripts encode the incidents you've already had. New failure shapes fall outside them, and the runbook wiki drifts further out of date every quarter.
• Status is a second job. The person fixing the problem is also the person writing updates for support and leadership.

James's 47 minutes are what that looks like. The tools exist and the data exists, but nothing connects them, so the on-call engineer becomes the integration layer, correlating six platforms in their head while communicating status and executing fixes.

The question behind CloudThinker SlackOps was simple: what if the integration layer could investigate? Instead of an engineer opening fourteen tabs, the evidence comes to the thread, already correlated, with the reasoning written down.

---

How SlackOps works

CloudThinker installs as a Slack app. Once it's in your workspace, you mention @CloudThinker in any channel it's been invited to, or message it directly, and ask in plain language. It answers in the thread using the connections you've already set up: AWS, Azure and GCP accounts, Kubernetes clusters, databases, Datadog, Grafana, PagerDuty and the rest.

01Signal

Alert lands

The PagerDuty or monitor alert posts to the incident channel as before.

02Evidence

Investigate

Metrics, logs, deploys, database and traffic checked against each hypothesis.

03Proposal

Plan in thread

Likely cause, the evidence, the change and its rollback, in plain words.

04Decision

Approve

A named person approves from the thread, on a laptop or a phone.

There are two ways teams use it:

• Direct messages for a quiet check: "is this cost spike real or a tagging change?" before you raise it with anyone.
• Channel threads for shared work: incidents, deploy reviews, cost reviews, security findings, where everyone needs to see the same evidence.

Cost, security, infrastructure and database expertise all sit behind the same mention. You don't need to know which specialist to ask. You describe the problem, and CloudThinker pulls in the right checks.

---

The 2:47 AM incident, in the thread

Here's James's incident again, this time with SlackOps in the channel. The alert posts as usual: [P1] payment-service p95 latency > 2s. The on-call replies in the thread:

"@CloudThinker payment latency is spiking and checkout is timing out. Find out why. Propose only, change nothing."

CloudThinker doesn't jump to a fix. It names the likely readings and what each one predicts:

Then it checks them, the same way an engineer would, and shows its work.

Deploy. The rollout history shows nothing new in fourteen hours:

kubectl rollout history deployment/payment-service -n payments

Ruled out.

Traffic. Request count on the checkout load balancer, five-minute buckets:

aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name RequestCount \
  --dimensions Name=LoadBalancer,Value=app/checkout-alb/<id> \
  --start-time 2026-03-12T01:30:00Z --end-time 2026-03-12T02:50:00Z \
  --period 300 --statistics Sum

Volume is running at about six times the usual level for that hour. A marketing campaign went out at 2:30 AM local time to a different region. That's the trigger.

Pods. kubectl top pods -n payments shows the EKS nodes around 87% CPU, with the deployment pinned at its replica count. Stressed, not broken.

Database. Connection state on the primary:

SELECT state, count(*)
FROM pg_stat_activity
WHERE datname = 'payments'
GROUP BY state;

The pool is saturated. Requests are waiting for a connection, which is where the latency actually comes from. Read queries from the product catalogue are competing with checkout writes for the same pool.

Within a couple of minutes the thread holds a finding instead of a forward:

Likely cause: traffic surge (~6x usual, campaign at 02:30) saturating the
payments DB connection pool. No recent deploy. Nodes at ~87% CPU.

Proposed:
  1. Scale payment-service from 8 to 24 pods (rollback: back to 8)
  2. Route catalogue reads to the read replica to free the primary pool

Each change waits for approval.

James reads it on his phone, approves both, and latency recovers. The support lead and the VP read the same thread, so nobody asks for a status update. When the developer who saw "something weird" earlier joins, the context is already there.

---

Nothing runs that you haven't allowed

CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval in the thread. Every request, check, approval and change is in the audit trail, linked from the thread.

---

From reactive to ahead of it

Faster incidents are half the value. The other half is catching problems in business hours, before they become 2:47 AM pages.

Because the same connections are always on, you can ask for the forward-looking checks you never have time to run:

"@CloudThinker based on the last 30 days, which services will hit memory or connection limits in the next week? Show the trend and the threshold for each."

"@CloudThinker the spring campaign launches on the 12th. Check whether payments, catalogue and the database can absorb three times normal traffic, and propose what to pre-scale."

"@CloudThinker any unusual access patterns on the payments account in the last 72 hours? Propose only."

A message at 2 PM that says "payment-service is on track to hit its memory limit within six hours; proposed change: scale from 3 to 5 instances" is one James reads at his desk, approves, and never thinks about at 2:47 AM.

When the same issue keeps coming back, say a service that hits memory limits every Thursday night during batch processing, the fix belongs in a Skill or a policy. That's how a one-off answer becomes a pattern the whole team inherits instead of something that lives in one engineer's memory.

---

Why this beats the traditional setup

The deeper difference is who does the joining. In the dashboard and ChatOps model, every tool is good at its own slice and a tired person stitches the slices together. In SlackOps, the stitching is the agent's job, it happens where the team already talks, and the person's job is the decision.

---

Getting started

An admin installs the CloudThinker app from Admin Settings → Integrations, then invites @CloudThinker to the channels where you want it. Start with a question that has a checkable answer:

"@CloudThinker show our AWS costs for this week by service, and flag anything that grew more than 20%."

"@CloudThinker look at the alerts from the last 24 hours in production. Group them by likely cause and show the evidence for each. Propose only, change nothing."

Run the second one the morning after a noisy night, and compare it with what the on-call pieced together by hand.

---

Related reading

• CloudThinker for Microsoft Teams: the same workflow for teams on Teams
• AgenticOps Needs Its Own Platform: why production access needs scoped credentials and approvals
• Why Root Cause Analysis Takes Hours: where the minutes go in a long incident
• Auto Mode

Try CloudThinker free and bring the investigation into the channel your team already watches.