New: Zabbix as an inventory source, with drift between what Zabbix monitors and what is on the network.See integrations
Root cause analysis for networks

One incident per failure,
not one alert per symptom.

rcaSense discovers your topology over SNMP, from LLDP and CDP up to BGP, IS-IS and LDP, and uses it to name the device, link or session that failed, what it took down, and why it thinks so.

Self-hosted · one Go binary · works with the Zabbix you already run

rcaSense map focused on core1: BGP, IS-IS, LDP, OSPF and VRRP sessions to core2, pe1, agg1 and agg2, with the BGP session to agg2 showing both ends, AS, hold and keepalive timers

Reads the protocols your network already runs

LLDPCDPOSPFOSPFv3IS-ISBGPLDPMPLS-TEVRRPHSRPEIGRPPIMLACPCiscoJuniperAristaHuaweiNokiaFRRSNMP v2c / v3
How it works

From a seed address to a named root cause

Four steps, all in one binary: build the inventory, discover the topology, correlate what monitoring reports, and hand the result to the tools your team works in.

STEP 01 · INVENTORY

Tell it where to look

Add sources in the UI and rcaSense crawls from them. Each fact about a device comes from the highest-priority source that has it, and anything set by hand wins.

  • IP, CIDR, range and hostname sources; NetBox and Zabbix as sources of record
  • SNMP v2c and v3 profiles picked by rules: device, group, CIDR, site, NetBox tag
  • Secrets sealed with AES-256-GCM, or read from environment or Vault
Devices table with type, address, vendor, source and status for every device
STEP 02 · TOPOLOGY

Search the network, not a diagram

Discovery polls every device it finds, in parallel, and keeps what it no longer sees until you say it is gone. The map starts from a search and expands from there.

  • Physical links, routing adjacencies and sessions, each with both ends' view
  • Search by name, IP, AS, protocol or state: bgp down, isis c02
  • Blast radius: what loses its path to the poller if a device fails
Topology overview with routers, switches, servers and VMs
STEP 03 · CORRELATE

Problems in, incidents out

Zabbix webhooks, SNMP traps and rcaSense's own state poller report problems. Fifteen seconds after the last change, rules over the topology decide what failed and what is only a symptom of it.

  • Every problem keeps each source's state; an OK from one never hides what another still sees
  • A confidence score with every factor written out: no black box
  • Simulate a failure to see the incident before it happens
Incident on the map: sw3 is the root cause, its links drawn red, the four devices behind it unreachable
STEP 04 · ACT

Send the answer where people work

Incidents go out as they open, change and resolve, from a queue in Postgres that retries without giving up. The topology also writes back into monitoring.

  • Keep: one incident per root cause, with the Zabbix alerts it explains linked
  • Zabbix trigger dependencies planned from the topology, written only after three runs agree
  • A webhook for everything else
Dashboard with open incidents, protocol health and incidents per day
Root cause

Deterministic, and it shows its work

No learning period and no guesswork: rules over the dominator view of your topology, with written evidence for every decision.

Topology-aware

A failed device is a root when bringing it back alone would restore the path to the poller. Everything behind it is a symptom, held under one incident.

Redundancy-aware

A device with two parents is a symptom only when both are down. Both cores failing together is one incident naming both, not two.

Layer-aware

An IGP adjacency down over an interface that is up is a session fault, "underlay is up". A BGP session cut by a failed link is explained by that link.

Directly impactedup, with ports or sessions toward the failure down
Unreachableno path from any poller; their alerts held as symptoms
No external connectivityreachable, but no path left to an exit
At riskup, but hanging on one side of a redundant pair
Measured

Fast enough to stay out of the way

58,088devices indexed, dominators included, in about 300 ms
300 / 300roots correct for single failures on a 240-device network
1.7 µssearch by name prefix at 58,088 devices
~9 MBone binary, UI embedded; Postgres for the inventory

Synthetic networks generated by rcaSense, one CPU core. Failures and events come from the same code that knows the topology, so the RCA figure checks the rules, not real alert noise.

Integrations

Fits the stack you already have

rcaSense doesn't replace your monitoring. It reads from it, explains what it reports, and writes the topology back.

Z
ZabbixWebhook intake, problem resync, host source, drift and trigger dependencies
K
KeepOne incident per root cause, with the alerts it explains linked
N
NetBoxSource of record for devices, roles and sites; cable drift
T
SNMP trapsLink, BGP, OSPF, LDP, TE tunnel and Juniper LSP traps
W
WebhookOpened, updated and resolved, with a link to the map
V
VaultSNMP and API secrets read from KV v2
O
OIDCLogin through your identity provider, or a trusted proxy
{ }
REST APIEvents in, topology, blast radius and incidents out
Deploy

Runs where your network data stays

Self-hosted only. Nothing leaves your network.

Recommended

Docker Compose

rcaSense and Postgres 16 on a distroless image, running as non-root. UI on :8080, traps on 162/udp.

# set RCASENSE_SECRET_KEY first
cp .env.example .env
docker compose up -d
Inventory mode

Single binary

One Go binary with the UI embedded. Migrations run on start; incidents survive a restart.

RCASENSE_DB=postgres://... \
rcasense serve -listen :8080
File mode

No database

One YAML file in, one topology snapshot out. Discovery and the map, without root cause analysis.

rcasense serve -c rcasense.yaml \
  -t topology.json -discover 15m

Break something. Watch it get named.

We'll run the containerlab demo with you: 19 routers, switches and servers running FRR, live BGP, IS-IS and LDP. Pull a switch and see one incident in under a minute.