The Rapax platform
Fault, performance, topology, and service management in one system — built for carrier networks, not adapted from IT monitoring.
Built for carriers, not adapted from IT monitoring
Most observability platforms were built to watch servers and were later pointed at networks. It shows in the data model: they think in hosts and metrics, so a fibre network becomes a list of devices that are up or down. Nothing in that model knows that an OLT port failure means forty-eight subscribers on a specific service tier just lost service, or that one of them carries an SLA with teeth.
Rapax models services, not just devices. GPON and XGS-PON topology, subscriber-to-port relationships, service tiers, and SLA commitments are first-class objects rather than tags bolted onto a metric. That is why the output of correlation is a service event with a subscriber count attached, instead of an alert with a hostname attached.
The four sections below are the four disciplines an operator actually buys. In most operations each one is a separate product from a separate vendor. Here they are one system sharing one data model, which is what makes correlation across them possible at all.
Fault management
Alarms arrive from every vendor in the network — Syslog, SNMP traps, webhooks, REST, streaming telemetry, existing Kafka — and normalise into a single event model. No device agents, no schema changes to what you already run.
What it replaces: the per-vendor fault manager, and the manual work of correlating between them. Cross-vendor faults correlate the way faults actually propagate, because every vendor’s alarms resolve against the same topology graph.
Performance management
Continuous collection with per-entity baselining. The point is not another dashboard — it is detecting the degradation that never crosses a static threshold until it is already an outage.
What it replaces: the standalone performance poller and the capacity-planning spreadsheet built from its exports. Performance data and fault data live in the same system, so a degradation trend and the alarm it eventually produces are the same story rather than two.
Topology and inventory
Everything above depends on knowing what connects to what. Nora maintains that graph from two sources simultaneously: live state polled from the network, and as-built documentation — circuit records, splice diagrams, service orders, customer contracts.
What it replaces: the static inventory system, the GIS export, and the spreadsheet that is more current than either. At a mid-market fibre ISP running GPON and XGS-PON across a multi-vendor footprint, Rapax built the topology graph from backbone to subscriber during deployment, consuming the operator’s existing Kafka streams. No agents, no schema changes, no downtime — under two hours.
Service management
This is the layer that turns network events into business ones. Services are modelled explicitly — subscriber to port, service tier, SLA commitment — so impact is expressed as customers and obligations rather than as interfaces.
What it replaces: optionally, the ticketing platform. Running ServiceNow, Jira, or Zendesk today and want to consolidate? Rapax migrates the history and you retire the licence. Prefer to keep it? Rapax integrates over REST and Frank works against it in place.
One assurance layer instead of one per vendor
Read those four sections together and the consolidation argument makes itself. Six vendors typically means six element managers, six alarm formats, six credential sets, six upgrade cycles, and six support contracts — plus a fault manager, a performance tool, an inventory system, and a ticketing platform layered on top. None of them share a data model, so nothing correlates across the boundaries between them.
Rapax is one layer above all of it. Every vendor’s telemetry normalises into the same topology graph and the same event model, so adding a seventh vendor is an integration Bruce builds — not a seventh console, a seventh runbook, and a seventh thing to watch.
To be precise about scope: Rapax does not replace a vendor’s element manager for configuring and provisioning that vendor’s hardware. It replaces your dependence on those element managers for assurance — for knowing what is broken, who it affects, and what to do about it. That is the layer where per-vendor tooling costs you the most and helps you the least.
How it scales
Path separation. Real-time correlation and historical analysis run against different stores, so a heavy capacity query cannot slow down an event in progress. This is why a single-store architecture degrades under exactly the conditions you need it most.
Elastic workers. A storm floods a monitoring system at the moment it can least afford to queue. KEDA scales collection and analysis workers against real-time demand, so capacity tracks the event rather than the average — and scales back down afterwards rather than sitting provisioned for the worst day of the year.
Horizontal architecture. Kubernetes microservices with stateless workers, so growth is added instances rather than a larger box and a migration weekend. The same deployment model runs a regional network and a multi-datacenter one.
Measured at v1.1: 10,000 events per second write throughput, 179.9 ms average API latency, and validation at 200 concurrent users, across 369 automated tests in 12 suites. An OWASP ZAP security audit across 97 URLs returned zero high-severity findings, with three medium-risk findings accepted and disclosed rather than quietly closed.
Where it runs, and what happens when something fails
Kubernetes microservices, cloud-agnostic — AWS, Azure, GCP, or entirely on-premise. For operators whose topology and subscriber metadata cannot leave their perimeter, on-premise is a procurement gate rather than a preference, and Rapax clears it including model inference: the platform runs against any LLM provider, local open-weight models included. Nothing has to leave your environment.
An assurance platform that degrades during a mass-outage event is worse than no platform, because by then the operations team has reorganised around it. The architecture is Active-Active across datacenters: if one fails, the second maintains surveillance and automation without a failover gap. It is designed to a 99.999% availability target — stated as a target, because availability achieved in any given deployment depends on the environment it lands in.
What it asks of you
One thing, and it is worth saying plainly: correlation quality is bounded by topology quality. If your inventory is wrong, root-cause identification will be wrong in exactly the same places. Nora’s reconciliation surfaces those gaps, but surfacing is not fixing — operators with poor topology data should expect a reconciliation phase and should budget for it. Any vendor telling you otherwise is selling you the demo rather than the deployment.
Run it against your own network
Rapax deploys in five days. You evaluate for thirty against success criteria you define in writing before anything is signed, for $25,000 — credited against the licence if you move forward. If it does not meet them, the evaluation ends and you owe nothing further.
The ask is fifteen minutes, not a demo. Book 15 minutes · sales@rapax.app · Meet the six agents