Incident investigation, from alert to reviewed patch

What starts an investigation

An alert webhook (Datadog, CloudWatch, Slack) or a question asked in Slack or MS Teams.

Support and product teams can ask the same questions in chat. Their questions follow the same read-only path as an alert.

How the investigation runs

• Context: gathers the alert, recent logs, related database records, and the code and commits around the failing path.
• Root cause: forms a hypothesis and cites the log lines, query results, and files behind it.
• Verification: A separate agent on a different model checks each proposed root cause against the evidence. This reduces unsupported conclusions; it does not guarantee correctness.
• Resolution: drafts a patch where a code change is the fix, and says so when it is not.

What the engineer receives

A .patch file plus the evidence behind the finding. An engineer reviews and applies it. The reply in Slack or Teams lists the evidence, the cause, how confident the agents are, and what they could not check.

Illustrative example

Checkout latency alert: logs show slow-query warnings on orders, a read-only EXPLAIN shows a full table scan, and git history shows a migration that dropped the index that morning. The patch restores the index for review.

Limitations

• It only sees systems you connect. A cause outside them can be missed.
• Environment-specific faults (hardware, third-party outages) are harder to confirm from logs and code alone, and Operate says when it could not verify.
• It does not apply fixes. An engineer reviews, tests, and ships every change.

Try it

Follow the setup guide, connect one log source and one repository, and run an investigation on a recent incident you already understand. See also self-hosted deployment and the Datadog integration.

Frequently Asked Questions