Incident Management
Declare, respond to, resolve, and learn from incidents, with on-call routing and postmortems.
The Incident Management page (Enterprise) takes over where an alert leaves off: declare an incident, work it with your team, resolve it, and capture what you learned, all in one place.
Declaring an incident
Click Declare incident and give it a title, description, and severity (critical, high, medium, or low). You're automatically added as commander, and KubeWatch pages whoever is currently on call (see On-call scheduling below) as a responder, so severity- and availability-based routing happens without anyone having to look up a schedule.
You can also declare an incident directly from a firing alert on the Alerts page. Its severity, title, and the alert's ID all carry over automatically, so the incident stays linked to whatever triggered it.
Working an incident
Each incident has:
- A status pipeline: declared → acknowledged → mitigated → resolved. Click any stage to move the incident there, forward or back (reopening a resolved incident clears its resolved timestamp so MTTR stays accurate).
- A timeline: every status change is logged automatically, and you can post free-text updates as the incident progresses.
- Responders: add teammates by user ID. The commander is added automatically when the incident is declared.
- Related incidents: a panel showing past incidents from the same alert rule (the strongest signal that it's the same recurring failure) or, absent that, matching severity within the last 90 days.
On-call scheduling
Under the On-call tab, create a schedule and add shifts (a user plus a start and end time). When an incident is declared, KubeWatch looks up whichever shift covers the current moment across your schedules and pages that person. Scheduling is manual by design. If two shifts overlap, the most recently created one wins the tiebreak, but nothing else resolves the conflict for you. That's a call for whoever owns the schedule.
Postmortems
Once an incident is resolved, a Postmortem section appears on its detail page. Write a summary, save it as a draft or publish it, and track action items (each with a description and open/done status) underneath. Postmortem authorship is human. KubeWatch doesn't generate the summary for you.
Insights
The Insights tab aggregates your own incident history: total and open incident counts, average time to acknowledge (MTTA) and time to resolve (MTTR), a breakdown by severity, and which alert rules generate the most incidents. This is plain aggregation over data KubeWatch already has, not a cross-tool analysis.
Notifications
Incidents notify the same Slack and email channels you already configured under Alerts → Notifications. That flow is one-way: KubeWatch posts updates out, and there's no way to acknowledge or resolve an incident from within Slack itself.