Every incident gets a triage report, written before you open Slack.
Radar opens an investigation the moment metrics, errors, or deploys cross the gates. It pulls the evidence, correlates the deploy, identifies the dominant error pattern, and writes you a one-paragraph verdict — with confidence and customer-impact tags.
payments-api p99 spiked to 11.4s (baseline 2.1s) starting at 14:21 UTC, two minutes after deploy v3.42.1 rolled to us-east-1. The latency is dominated by PaymentProcessor.charge calls timing out against the Stripe webhook handler. users-api is seeing cascading 5xx via the job-events SQS queue (depth ×4.2 vs baseline). Recommend: roll back v3.42.1.
- 14:21:04CloudWatch · payments-api/web · p99 11,420ms
- 14:21:38Logs · 487× "PaymentProcessor.charge timeout"
- 14:19:11Deploy · v3.42.1 · acme-payments · GitHub
- 14:22:00SQS · job-events depth 4,200 (baseline 1,000)
What changes for the on-call engineer
The first 5 minutes of every incident are already written for you — service, deploy, error, blast radius.
Each verdict ships with a confidence score and a customer-facing flag, so on-call knows whether to wake the team.
Every claim points to the underlying log group, metric, or deploy — one click away. No grepping. No archaeology.
How it works
Trigger
An error-watch gate, a metric anomaly, or a manual button kicks off the investigation.
Gather
Radar pulls the relevant CloudWatch metrics, log samples, recent deploys, and queue depths in parallel.
Verdict
The agent writes a one-paragraph plain-English verdict with confidence, impact, and a recommended next action.