Pull the timeline on your last ten SEV2s and mark the moment someone knew the cause. In most teams that mark lands close to the end. The actual repair, a rollback or a config change, is quick. What takes the time is everything before it: reading logs, checking the deploy feed, ruling out the dependency that was slow last week, and asking in the channel whether anyone touched the thing that just broke.
Triage is a reading problem
The on-call is not stuck because the fix is hard. They are stuck because the evidence is scattered across six tools and none of them agree on what time it is. Triage is a reading problem, and reading messy telemetry under time pressure is exactly what a language model is good at.
This is why we built Ember to read first. The moment an alarm fires, it pulls the logs, traces and recent deploys, correlates them, and hands the on-call a ranked cause with the evidence it used. The human still decides. They just decide with the reading already done.
What shortening triage does to MTTR
- The clock that matters is time to a confident cause, not time to a fix. Cut the first and the second follows.
- Fewer people get pulled in, because the context is in one place instead of twenty messages deep in a thread.
- The postmortem is easier, because the timeline was written as the incident ran rather than reconstructed the next day.
The fix was never the slow part. Finding out what changed was.
Automating triage does not mean taking humans out of the incident. It means giving them back the minutes they spend reading, so they can spend them deciding.