Getting started
Your first incident
Here's what actually lands in your inbox when something breaks — and how to read it in twenty seconds.
Anatomy of a narrative
Every incident has the same shape: what broke, what's affected, what changed right before it, and a suggested next step. No graph-staring required — though every claim links back to the underlying trace, metric, or deploy if you want to verify.
A real example
"At 03:12 UTC, checkout p99 went from 180ms → 12.4s and started returning 504s. Root cause is payments-svc: outbound calls to Stripe are timing out. Four minutes earlier it shipped 3d9a1c — a stripe-node 14→15 bump that defaults to IPv6, which your egress NAT doesn't route. Suggested: roll back to 5f20e8."
Acting on it
From the incident you can acknowledge, roll back a correlated deploy, or open the drafted fix-forward PR — without leaving the narrative. Every action is written to the audit log.
Tuning the noise
If an incident wasn't worth paging on, mark it. Inkvo folds that signal back into the per-service baseline so the next one is quieter. Over a couple of weeks the feed converges on the things that actually matter.