The Investigation Window
What changed, why it broke, what is affected, next best action, with the evidence one click away.
Incident Reasoning
Explain incidents with evidence: in minutes, not war rooms
When REAP’s own rules raise an incident, or your monitoring raises one through ServiceNow (opens in a new tab) or Jira (opens in a new tab), REAP starts working: reading the state of the network, tracing topology, correlating configuration changes and building the complete picture, with the evidence behind each conclusion.
The buyer’s question
“Why is this path down, what changed, and what is affected?”
Today the answer lives in six tools and two senior engineers. Restore takes an hour; the real cause is found days later, if at all. That is senior-engineer time spent collecting evidence instead of fixing the next thing, and a cause that returns because nobody proved it. The time to start is after the P1 that took a week to explain.
What REAP does
- Correlates topology, configuration, telemetry, tickets and change history into one investigation
- Decides what evidence to gather next and shows it with every conclusion, the way a senior engineer does
- Surfaces the cause, the affected devices and paths, and the next-best diagnostic action
- Flags active/standby pairs that are out of sync before the second failure
- Works on the incidents your monitoring already raises: picks up the ticket in ServiceNow (opens in a new tab), investigates against the network it has discovered and writes the Investigation Window and evidence links back; a summary reaches the on-call engineer in Slack (opens in a new tab) or Microsoft Teams (opens in a new tab)
What you get
Outputs, not dashboards
Time to answer, measured
Recorded for every investigation and reported as P50 and P95: the P50 target is agreed per pilot, and the P95 is always reported.
Tier 1 that resolves
Guided evidence lets tier-1 and tier-2 engineers close what used to escalate; experts review evidence instead of collecting it. The value is hours returned to your team, not headcount cut.
Evidence shown
Every conclusion, traceable
What you can see live in a 20-minute demo on our lab network: an incident opened with what happened, why, what is affected and what to do next, with the commands and outputs behind each; a question answered across vendors; forward and reverse path traces, now and at a past point in time; ping, traceroute and a packet capture run and analyzed; an approved runbook executed with its record. In a pilot, 5–10 historical incidents whose root cause you know, and REAP does not, are replayed from the ticket, your configuration archive and the logs you provide; your engineers score correctness and trace each conclusion to its source.
What changed
CHG-1234 edited object group OG-ERP on plant-a-core-2 at 21:14: its members were replaced (10.20.5.0/24 → 10.20.50.0/24) so a second ACL could reuse it. ACL-ERP-IN already referenced the group.
Why it broke
ACL-ERP-IN permits ERP return traffic by matching OG-ERP. With the members replaced, traffic from the ERP servers (10.20.5.0/24) falls to the final deny. The link and the OSPF adjacency to dist-3 never changed, so nothing alarmed.
Impact
ERP return traffic to Plant A order entry (10.30.12.0/24) dropped on core-2 since 21:16: 1 device, 2 subnets, 1 service path. Undetected for 4 h 51 min; no probe watched the ERP path.
Next best action
Restore OG-ERP to its 21:13 members (runbook RB-07, awaiting approval); re-test ERP reachability; re-implement CHG-1234 with a separate group for ACL-B; add a probe on the ERP path.
Evidence
- 02:07:40config diff plant-a-core-2, 21:13 → 21:14→ OG-ERP: −10.20.5.0/24 +10.20.50.0/24; ACL-B: +permit ip object-group OG-ERP any
- 02:08:05show ip access-lists ACL-ERP-IN (two reads, 25 s apart)→ OG-ERP entry 0 matches; final deny 3,412 → 3,918
- 02:08:22traceroute from Vlan312 to 10.20.5.10→ no reply beyond plant-a-core-2; core-1 path unused (OSPF cost 10 vs 20)
- 02:08:31show ip ospf neighbor→ dist-3 FULL/ -; no link event in syslog since 21:00
- 02:08:50ServiceNow CHG-1234→ “no impact expected” · closed 21:20 · no post-check recorded
- 02:11:24leading cause corroborated by 4 independent sources · verification pending RB-07 and a reachability re-test
How a pilot measures it
The scorecard categories this door is judged on
| Measure | Default target (agreed per pilot) | Source |
|---|---|---|
| Diagnosis quality | ≥80% correct or materially useful root cause · ≥90% evidence traceable | Incident Validation Report |
| Time to answer | Time to detect (deterministic rules): design target under 4 minutes · time to an evidence-backed answer: P50 agreed per pilot · P95 always reported | Instrumentation |
| Human effort | ≥50% fewer engineer-minutes per investigation · tools per investigation 6 → 1–2 | Baseline vs. pilot log |
| Trust | ≥80% of conclusions accepted by senior engineers | Engineer scoring |
Related
Keep reading
Change Assurance
Evidence on every change, before and after.
Learn moreHow REAP reasons
Evidence, next step, shown not asserted.
Learn moreValue calculator
What faster diagnosis is worth on your baseline.
Learn moreOpen this door in 45 days.
One production domain, your baseline in week 0, a decision in week 6.