Mirav Vigil · See a real report

Ten faults.
Ten verdicts.
Every one with
its evidence.

Below is exactly what Vigil produces, with nothing tidied up — an annotated triage report and the verdicts the engine wrote for ten different fault types, each one traceable to the command that produced it.

About this data. The reports shown are generated by the production engine running against a demonstration fault set. Hostnames, circuits, addresses and AS numbers are synthetic. The diagnostic logic, thresholds and report format are the real ones. Aggregate figures quoted further down are measured on the live deployment; the operator is not named.
Anatomy of a report

Eight sections. Evidence first,
verdict last.

The ordering is deliberate — an engineer should be able to reach their own conclusion before reading Vigil's, and disagree if the numbers don't support it.

A full Mirav Vigil LinkDown triage report showing all eight sections from link details through to the RFO verdict, plus retained raw command output and the engineer feedback widget.
The complete report for a LinkDown on a 100G backbone LAG.
SectionWhat it answers
1 · Link detailsWhich link, which LAG, and — resolved from topology rather than the interface description — which device is genuinely at the far end.
Outage windowWhen it actually went down and whether it has come back, derived from device event logs anchored to the alarm. Plus flap count in the window.
2 · Physical port statusAdmin vs operational state, and how many LAG members are genuinely active.
3 · Optical powerRX and TX per member, with dark members flagged against the transceiver's own low-alarm threshold. This is the section that decides most LinkDowns.
4 · Interface errorsAlignment, CRC, FCS, symbol errors in and out — the difference between "down" and "degraded".
5 · Loopback testShown only when it would actually be diagnostic. When it isn't, Vigil says why rather than printing an empty section.
6 · Remote endFar-end state when it could be collected — and an explicit statement when it could not.
7 · Event log timelineThe device's own events around the alarm, scoped to the window, with this alarm's flap marked among any others.
8 · RFO / next actionThe verdict, its confidence grade, the evidence behind it, and the queue to dispatch to.
Raw command outputThe exact CLI responses, retained. L2 never has to re-collect.
NOC reviewAccept / needs-improvement / reject, with a structured reason. This is how the logic gets better.
Ten faults, ten verdicts

Every alarm family,
with the engine's own words.

Verbatim output from the diagnostic engine — nothing rewritten for the website.

AlarmConfidenceVerdict
LinkDownMEDIUMLAG down — all measured members optically dark (RX ≤ −35 dBm) with TX present. The entire trunk lost light simultaneously → fibre cut / DWDM span fault, not a local SFP.
LinkDownMEDIUMLAG is currently UP and operational. The link recovered before triage ran — a transient flap that has since cleared. No active fault.
LAG port add-failMEDIUMLACP could not add the member because its L1 is down. Underlying cause: local RX dark (−40 dBm) against a −17.4 dBm low-alarm threshold.
Service site downHIGHEVPN-VPWS — local access circuit is up, remote AC unresolved → remote PE / BGP-EVPN control plane. Not a local fault.
Service site downHIGHService down — local access circuit operationally down. Fault is on this node.
BGP peer state changeLOWSession is in CONNECT but no specific cause corroborated. Check NOTIFICATION history and peer-side state. Vigil declines to guess.
SNMP unreachableHIGHNode is REACHABLE — SNMP sysName responded and ping shows 0.0% loss from the NMS vantage. False alarm.
Node unreachableHIGHNode is UNREACHABLE — 100% ping loss and SNMP timeout, both from the NMS vantage. Genuine outage, escalate.
PSU removedHIGHPower supply removed from slot 1. No operational redundant PSU detected — immediate power-loss risk.
SFP removedMEDIUMSFP state unclear — re-reading the port after optical readings settle rather than asserting a removal.
Calibration is the feature. Rows 2, 6 and 10 are a recovered flap, an uncorroborated BGP event and a deliberately deferred read — each graded accordingly. A system that is right about how sure it is, is a system a NOC can work from.
Look at rows 4 and 7. "Remote PE, not your fault" and "reachable, false alarm" are the two verdicts that save the most money — and they are the two an overloaded L1 shift is least likely to establish at 2 a.m.
The queue view

Verdict and confidence
before anyone opens it.

Mirav Vigil ticket queue: each row shows the alarm type, hostname, priority, fault state, a one-line root cause and the confidence grade.
Each row already carries its root cause and confidence — the shift triages the list, not the tickets.
Measured, not projected

What the live deployment
actually produced.

Figures from the deployed system on a production carrier IP/MPLS backbone. The operator is not named; nothing here identifies a network or a circuit.

1,753
network fault tickets ingested and classified
188
distinct routers reached, read-only, through the jump host
31 s
median ticket → evidence-backed verdict · p90 87 s
47%
of investigated faults already self-recovered or transient
9
alarm families with dedicated diagnostic logic
~70
distinct read-only commands in the collection vocabulary
100%
of verdicts carry the raw command output that produced them
0
configuration changes, ticket writes or clears — by design

Timing is machine time from ticket pickup to stored verdict, measured across investigations that completed collection. In a recent re-triage of the ten most recent live tickets, all ten produced a verdict; nine graded HIGH and one MEDIUM.

Scope & fit

What's in,
and what's next to it.

Clear boundaries are part of why this gets approved quickly. Here is where Vigil sits in your operation.

🎯

Triage and diagnosis

Vigil owns the L1 collection-and-conclusion loop: evidence, root cause, confidence, dispatch and recovery tracking. That is the whole job it does, and it does it on every ticket, every shift.

🧩

Alongside your NMS

Your monitoring stack detects and correlates. Vigil takes it from there — logging in, reading the device, and turning an alarm into an evidenced conclusion. The two are complementary, not competing.

🤝

Remediation stays yours

Dispatch, field action and ticket closure remain your team's call, with better information in front of them. If you later want supervised remediation, that is a deliberate next step with its own guardrails.

Speed matters more than you'd think. Optical readings and device event buffers decay within minutes of a fault. A large part of why Vigil's verdicts hold up is simply that it collects the evidence while the fault is still live — which is also the part a busy L1 shift can never guarantee.
Talk to us

Run it against
your queue.

Send us a week of anonymised alarm subjects and we'll show you what Vigil would have written into each ticket — and how much of that week never needed a person.

Book a 30-min walkthrough deepak@d2c.in