Blog / Triage & routing / FIG. 168
AI-Enabled Incident Triage for Ops Teams
AI-enabled incident triage classifies alerts, suggests severity, and routes to the right on-call, without touching remediation. The pattern and rules.
Incident triage is the stretch between an alert firing and the right person working the right problem. Is it real? How bad? Who owns it? AI-enabled incident triage automates those judgment calls, classifying alerts, suggesting severity, and routing to the owning team, while leaving every fix to humans and tested runbooks.
What incident triage decides
Every alert raises the same handful of questions:
- Is it real, or noise?
- Is it a duplicate of an incident already open?
- What severity: SEV1 through SEV4?
- Which service and team own it?
- Are customers affected right now?
- Does it need an incident commander?
These are closed questions, which is exactly the shape a decision model answers well.
Where verdicts help
Noise versus actionable. Judge alert text plus a little recent context. Flapping alerts and known-benign patterns get labeled instead of paging someone at 3 a.m.
Severity from facts. "Customer-facing and failing now?" beats a keyword match on "critical" every time.
Ownership routing. Map service and component to the team that owns them.
The Jevops SRE log triage build is a cataloged example: it sorts streaming logs into page, digest, or resolve, and pages humans only for high-confidence incidents, as reported by its author. Architecturally, this is the pre-filter cascade from five cascade architectures: destroy obvious noise, escalate everything uncertain.
What stays human
Remediation stays human: rollbacks, failovers, data repairs, config changes. None of them run on a lone verdict, per the verification rule. AI triage decides who looks, never what gets changed.
Downgrading severity and declaring an incident resolved also stay human, and so does the postmortem.
Designing it safely
- Asymmetric thresholds. Escalating should be easy and suppressing hard. A wrongly suppressed alert is the incident report you really don't want to write.
- Fail open. If the verdict API is unavailable, alerts route exactly as they did before AI existed.
- Log every suppression with the question version, so the postmortem can see why an alert went quiet (audit trail spec).
- Watch for drift. Alert formats change when services change, and a question tuned last quarter can quietly misread this quarter's alerts.
Where teams start
Start in shadow mode for two weeks: verdicts are recorded, humans still triage everything, and you compare. QA teams often begin with flaky-test and bug triage, covered in Jev for QA engineers. Data teams start with pipeline-failure alerts, per Jev for data teams.
Frequently asked questions
What is AI-enabled incident triage?
Using models to classify, prioritize, and route alerts and incidents before a person engages, so the right responder sees the right problem first.
Can AI resolve incidents automatically?
Remediation should stay with humans and tested runbooks. AI triage decides who looks, not what changes.
Won't AI suppress a real incident?
It can, which is why suppression thresholds are strict, every suppression is logged, and new alert types start in shadow mode.
Is AI incident triage fast enough?
For deciding who to page, yes: verdicts take a fraction of the time a human needs to read an alert. For automated failover, it's the wrong tool.
What data does the model see?
Only the alert text and context you send. Keep secrets and customer data out of the payload. The model itself is covered in what Jev is.
Numbers throughout are as reported by the build authors, not verified by shipwithjev. Code-shaped examples are pseudocode; the official docs live at docs.typesafe.ai.