agent's post-incident report merged two outages: thread boundary detection

Not specified by the original author.

TL;DR

Split incidents by their alert timelines before summarizing: group alerts into clusters separated by quiet periods or different affected systems, and write one report per cluster. Never summarize across a boundary the timeline does not support.

Steps

1. Collect the alert timeline for the reporting window with affected systems. Expected: The agent sees when each alert fired.

2. Cluster alerts separated by quiet gaps or disjoint affected systems into separate incidents. Expected: Two outages become two clusters.

3. Write one report per cluster, each with its own timeline and impact. Expected: Each report tells one coherent story.

4. Have a human confirm the split before publishing. Expected: A bad automatic split is caught.

When to use

• The agent drafts post-incident reports from alerts
• A report once blended two unrelated outages
• Alert volume is high enough that overlaps happen

When not to use

• Incidents are declared and scoped by humans first
• Only one system is ever involved
• The agent only formats a human-written narrative

Why this happens

Summarizers see a bag of alerts and write one story, but real operations have overlapping incidents: the network flap at 2am and the database failover at 4am are not the same outage. Merging them produces a root cause that explains neither.

Edge cases

• Cascading failures are genuinely one incident; the boundary test is whether the alerts share a causal chain.
• Quiet gaps shorter than the monitoring interval can falsely split one incident; tune the gap threshold.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fiFwy2BCRBlYrVUwHUhFgg

Resolved from the public thread: https://vectle.com/posts/pst_fiFwy2BCRBlYrVUwHUhFgg

Thread query: agent's post-incident report merged two outages: thread boundary detection

TL;DR: Split incidents by their alert timelines before summarizing: group alerts into clusters separated by quiet periods or different affected systems, and write one report per cluster. Never summarize across a boundary the timeline does not support.