Introducing CloudThinker Incidents

Agentic incident management that investigates the way your best engineer would.

---

The 3 AM problem

It's 3 AM. Your phone buzzes: "Database connection timeout."

You get to your laptop and start the routine every on-call engineer knows:

1. Open a dozen browser tabs
2. Jump between monitoring dashboards
3. Dig through log streams
4. Trace the request path across services
5. Line up timestamps by hand
6. Hope something stands out

By the time you find the root cause (a misconfigured connection pool after last week's deployment), 45 minutes have gone by. Your users felt every one of them.

Meanwhile, three more alerts fired for the same issue. Your inbox is chaos, and tomorrow's post-mortem is already on the calendar.

The tools got prettier and the dashboards got richer. The model didn't change: people do all the thinking while the tools display data.

---

Why the traditional model breaks

The problem isn't a shortage of data. It's that every step between "alert fired" and "cause found" is a manual join.

• Alerts are per-symptom. One saturated pool fires a timeout alert, a latency alert, a CPU alert and an error-rate alert. Each arrives on its own, and someone has to notice they're the same incident.
• Dashboards are per-tool. Metrics, logs, traces and deploy history each live behind their own UI and time picker. Correlating them happens in the engineer's head.
• Services are treated as a flat list. The alert names the component that complained, not the one that failed, and not the twelve that depend on it.
• The knowledge walks out. The engineer who knows "this one is always the pool config" is on holiday, or has left. The last post-mortem is a PDF nobody re-reads.

None of these get better with a nicer dashboard. They get better when something does the joining.

---

A new approach: agentic incident management

CloudThinker Incidents is an agentic incident platform, not another alerting dashboard or log aggregator. It's built on one premise: your incident management system should investigate. It forms hypotheses, gathers evidence and identifies the root cause while you focus on the response.

It rests on four pillars:

01Investigate

Agentic RCA

Hypotheses tested against evidence, with a confidence score on the result.

02Scope

Topology-aware

The blast radius across upstream and downstream dependencies.

03Connect

Bidirectional

Alerts in, context pulled during the investigation, status synced back.

04Remember

Continuous learning

Patterns and fixes from past incidents speed up the next one.

1. Agentic root cause analysis: an investigator that works the problem like your best engineer.
2. Topology-aware intelligence: your system understood as a connected graph.
3. Integrations: two-way connections to the monitoring stack you already run.
4. Continuous learning: sharper with every incident you resolve.

---

1. Agentic root cause analysis

Traditional incident tools give you dashboards and expect you to connect the dots. CloudThinker gives you an investigator that does the detective work. It reasons about your system: forms hypotheses, tests them against evidence, rules out false leads, and converges on the root cause with a confidence score.

When an incident triggers, the agent starts a structured investigation. It gathers relevant signals across your infrastructure: metric anomalies with before/after deviation analysis, log entries with deep links to the source, distributed traces showing request paths, recent configuration changes, and deployment events in the time window.

01Ingest

Alert arrives

Webhook or connection, checked against the 24-hour dedup window.

02Gather

Evidence

Metrics, logs, traces, config changes and deploys in the window.

03Reason

Test hypotheses

Each theory is checked against the evidence and kept or ruled out.

04Conclude

Root cause

A confidence score and one to three ranked remediation actions.

05Close

You resolve

Status syncs to the source and the RCA report is generated.

Here's what that looks like on the 3 AM page. The alert says the database is timing out. Two readings fit, and they predict different things:

1. A traffic spike exhausted the connection pool. Predicts request volume well above baseline, with connections rising in step.
2. The pool is misconfigured after a deploy. Predicts normal traffic, a recent config change, and connections pinned at a ceiling.

The agent pulls the evidence each reading needs. Connection counts on the Aurora cluster, for example, come from CloudWatch:

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DatabaseConnections \
  --dimensions Name=DBClusterIdentifier,Value=orders-aurora \
  --start-time 2026-10-07T01:00:00Z --end-time 2026-10-07T03:30:00Z \
  --period 60 --statistics Maximum

and what those connections are doing comes from the database itself:

SELECT state, wait_event_type, count(*)
FROM pg_stat_activity
GROUP BY state, wait_event_type
ORDER BY count(*) DESC;

Request volume is normal, so the traffic-spike reading is ruled out. Deployment history shows a config change two hours earlier, connections peak at 275, CPU sits at 100%, and the error pattern starts at the change. The second reading is confirmed, and the agent says so with its confidence and the evidence chain behind it.

Every finding comes with a confidence score from 0 to 100%, so you know how much weight to give it. The agent also suggests one to three remediation actions, ranked by impact and urgency.

Instead of 45 minutes across dashboards, you start with a root cause summary, the evidence that supports it, specific remediation steps, and a confidence level to guide your response. It never sleeps, doesn't forget, and can look across your whole stack at once.

---

2. Topology-aware intelligence

Most incident tools treat your infrastructure as a flat list of services. Your system is a graph of interdependent components, and CloudThinker treats it that way. When an alert fires, you see the blast radius: every upstream and downstream dependency that might be affected.

When an incident arrives, CloudThinker resolves the affected components against your infrastructure topology. Service names map to topology nodes, hostnames resolve to their parent services, and cloud resource ARNs link into your dependency graph. No manual tagging required.

Once the affected service is known, CloudThinker traverses the dependency graph to calculate impact: direct dependencies (services that call or are called by the affected component), transitive impact (second-order effects through the system), and estimated user impact (how many active sessions or requests are at risk). "The database is down" becomes "The database is down, affecting 3 upstream API services, 2 background workers, and approximately 12,000 active user sessions."

The blast radius renders on an interactive topology map. Affected nodes highlight by severity, and dependencies show direction, so you can see the full scope in seconds and prioritize accordingly.

---

3. Integrations

CloudThinker doesn't ask you to rip out your monitoring stack. It connects to it, in both directions.

01Monitoring stack

Your tools

• ObservabilityMetrics, logs and traces
• AlertingRouting and escalation
• Cloud monitoringNative cloud metrics

HMAC, API key or bearer auth

02Investigation

CloudThinker Incidents

• Correlate and dedupOne incident per underlying issue
• InvestigateEvidence, hypotheses, confidence
• Blast radiusResolved against your topology

Status syncs back to source

03Where the team works

Notifications

• SlackIncident updates
• Email and in-appPer-user preferences
• RCA reportPDF at post-mortem

Every status change audited

Your monitoring tools can push alerts to CloudThinker by webhook, with secure authentication (HMAC signatures, API keys, bearer tokens), flexible field mapping to normalize any payload format, and automatic payload validation. For deeper integration, CloudThinker connects directly to your monitoring platforms. That enables context fetching (pulling extra metrics, logs and traces during an investigation), status sync (resolve an incident in CloudThinker and the status syncs back to the source), and enrichment with metadata from the originating platform.

CloudThinker integrates with observability platforms for metrics, logs and traces; alerting systems for routing and escalation; cloud provider monitoring for native cloud metrics; and error tracking tools for application-level detail. It supports 15+ platforms across these categories, with more added regularly. The goal is to make the tools you already have more useful, not to lock you in.

Wherever alerts come from, you get one view: all incidents in one timeline, consistent severity classification, unified search and filtering, and cross-platform correlation.

Learn more about setting up integrations →

---

4. Continuous learning

Every incident your team handles carries signal. CloudThinker captures it.

It identifies recurring issues across your incident history: similar error signatures, time-based patterns (deploy-day issues, traffic spike correlations) and service-specific failure modes. When a new incident matches a known pattern, the investigation starts from that pattern.

CloudThinker remembers what worked: which remediation actions resolved similar issues, how long different approaches took, and which false leads were ruled out. That knowledge stays when team members rotate.

The more incidents you resolve, the better it understands your environment: which services are most interconnected, what normal looks like for your metrics, and where problems usually start. Its first hypothesis gets more accurate over time.

---

Key capabilities

Beyond the four pillars, CloudThinker Incidents includes capabilities for the rest of the incident workflow.

• Alert correlation groups related alerts into a single incident. When several notifications fire for the same underlying issue, you see one investigation instead of twenty duplicates, with occurrence tracking and a 24-hour deduplication window.
• Live Context lets you watch the investigation in real time: the current phase, the hypotheses being tested, evidence as it arrives, and confidence as it changes. The reasoning is visible, so you can check it.
• RCA reports are generated as a PDF when an incident reaches post-mortem status, with the complete timeline, evidence chain, root cause summary, remediation actions and blast radius visualization. Ready to share with stakeholders or archive for compliance.
• Multi-channel notifications reach your team where it works (email, Slack or in-app), with per-user preferences and forced notifications for critical events.
• A flexible incident lifecycle goes beyond the standard linear flow: incidents can be marked as false alarms, put on hold or reopened as understanding changes, with every status change logged in an audit trail.

---

Why this beats the traditional approach

The deeper difference is who does the joining. In the traditional model a person correlates alerts, dashboards and change history under pressure. Here the agent does that work and shows its reasoning, and the person spends their attention on the decision: the agent investigates, you decide.

Remediation follows the same rule. Under Auto Mode, every workspace starts in Manual: the agent proposes the fix and a named person approves any change before it runs. Once a fix is well understood and written into a runbook or policy, you can move that class of action to Auto, where covered actions run without interruption and anything new still escalates to a person.

---

Getting started

CloudThinker Incidents is available today for all CloudThinker customers.

Setup takes minutes:

1. Navigate to Incidents in your CloudThinker dashboard
2. Complete the onboarding wizard (4 quick steps)
3. Connect your first integration via webhook or full connection
4. Configure your default topology view for blast radius analysis

The next alert that fires will start an investigation automatically.

Once it's running, you can ask about any incident in plain language:

"Why did the orders database start timing out? Show me the evidence for each hypothesis you ruled out."

"What's the blast radius of this incident? Which services and roughly how many user sessions are affected?"

"Have we seen this error signature before? What fixed it last time, and how long did it take?"

For a step-by-step guide to wiring up detection, runbooks, approvals and war rooms, read how to use CloudThinker for incidents. For why diagnosis is the stage worth compressing first, see how to reduce MTTR.

Get started with CloudThinker Incidents →

---

CloudThinker Incidents is available now for all CloudThinker platform customers. Contact your account team or visit our documentation to begin setup.