Skip to main content

​
Automated incident investigation

Incident Investigator uses the alert, recent changes and available service signals to investigate likely causes. Findings include evidence, next steps and any unresolved questions. Open Agents → Root Cause Analysis in the app. Reuse the integrations already connected to your project. Configure the trigger and result destination for automatic investigations, or ask Annie directly.

​
Investigate a deployment alert

Example: PagerDuty reports checkout-api errors after a rollout. Pods are ready, but requests fail. The investigation should compare the deployment change with application health, rather than treat pod readiness as recovery. Needed: the alert, affected service and time window, plus access to relevant infrastructure and observability data in the project. PagerDuty is required for a PagerDuty trigger; Slack is required only for Slack delivery. Missing health signals must be reported as missing evidence. For an on-demand investigation from a coding assistant, connect Annie Remote MCP and use:
A useful result links the relevant changes and signals, separates hypotheses from confirmed evidence, and explains what remains unresolved. A connection-pool change may explain database timeouts if the evidence supports it; nearby timestamps alone are not proof. For automatic activation, follow the PagerDuty setup or incident.io setup. Your automation rules determine which events start an investigation. Configure Slack delivery only if needed. Anyshift investigations use the agent run allowance. See pricing. If your own agent only needs production evidence, use Graph MCP instead.

​
Slack channel registration

1

Register Annie on your incident channel

In your Slack incident channel, run:
Example: /register_annie_on_call @Datadog
2

Wait for an alert

Annie handles matching alerts according to the channel registration and automation rules.
3

Read the findings

Annie reports likely causes, evidence and next steps, including any missing data.
Want to customize how Annie responds to specific messages? See Annie Automation.

​
Alert ingestion sources

Annie investigates incidents originating from four channels:

PagerDuty

Investigate matching incident events using the configured automation rules.

Incident.io

Webhook integration for automatic RCA. Results posted as comments.

Slack

Mention @Annie with incident details for on-demand investigation.

Annie Remote MCP

Trigger RCA from your IDE during development.

​
How it works

Investigation runs against the versioned knowledge graph of your stack, where every IAM update, Helm rollout, Terraform apply, and merged commit is a node. “What changed in the last 24 hours that touches the payment-service deployment chain?” resolves as a graph diff, not a manual hunt across CloudTrail, kubectl, and git logs. Completion time depends on the investigation. Results go to the configured destination.

​
Postmortem-ready output

When Annie completes an RCA, you receive:
A concise summary suitable for stakeholder communication:
“The checkout API latency spike was caused by DynamoDB read throttling after a 5x traffic increase from the marketing campaign. Immediate mitigation: increase read capacity to 500 RCU.”
Chronological sequence leading to the incident:
  • 09:55 - Marketing campaign email sent
  • 10:02 - Traffic increases 5x
  • 10:05 - DynamoDB throttling begins
  • 10:07 - P99 latency exceeds threshold
  • 10:08 - Alert fires
Technical details with evidence from your systems:
  • What happened
  • Why it happened
  • Supporting evidence from logs, metrics, and configuration history
List of impacted infrastructure with the specific impact on each.
Actionable fixes organized by urgency:
  • Immediate: Resolve the incident now
  • Short-term: Prevent recurrence this sprint
  • Long-term: Systemic improvements
For hypotheses that map to a concrete code change, the Propose Fix button on the hypothesis card opens a pull request with the diff. See Propose Fix.

​
Real-world examples

“RDS connection timeout on prod-api service”
Root Cause: Security group sg-prod-db was modified at 14:32, removing the inbound rule for the application subnet (10.0.1.0/24). Evidence:
  • Security group change detected 15 minutes before alert
  • No changes to RDS instance itself
  • Application logs show “connection refused” starting at 14:35
“Pod restarts exceeding threshold for payment-service”
Root Cause: Deployment payment-service:v2.3.0 was deployed 1 hour ago and has a memory leak. Pods are being OOMKilled. Evidence:
  • New image deployed at 10:00
  • Memory usage increased from ~300Mi to 600Mi under load
  • Pod memory limit is 512Mi (see Kubernetes resource limits)
  • OOMKilled events in Kubernetes
“P99 latency > 2s on checkout API”
Root Cause: DynamoDB table checkout-sessions is throttling due to exceeded read capacity. A marketing campaign at 10:00 AM increased traffic 5x. Evidence:
  • Traffic increased from 100 req/s to 500 req/s at 10:00
  • DynamoDB throttled requests spiked at 10:05
  • Provisioned RCU (100) is insufficient (see DynamoDB provisioned throughput)

​
Get Started

Create Account

Sign up for Anyshift

Request Demo

See RCA in action

Deploy Watcher

Check a production change without waiting for an incident alert.

Proactive

The flip side of RCA. Annie finds and predicts issues before an alert fires.

Explore & Ask

Ask follow-up questions about any incident in plain language.

Production Graph

The versioned graph Annie traverses to find “what changed”.

Change History

Inspect recorded changes within your plan’s data history.