Evidence
What 27,000 Devices Under One NOC Actually Looks Like
Written by
Jayesh Verma
Published
August 2026
Reading time
9 min read
A Tier-1 telecom operator in India, three ingestion pipelines that had never met, and the decision that mattered most: the agent suggests, the engineer decides.
The first thing to understand about a 27,000 device estate is that nobody was failing at their job. The operator had monitoring. It had element managers, it had counters, it had dashboards. What it did not have was a single place where the state of the network existed as one thing at the moment it changed.
Fault and performance data arrived continuously over three different mechanisms. SNMP traps and metrics from the devices. Kafka event streams. Poll-based collection. Each of those was a working pipeline. None of them could see the other two. So the network told its story three times, in three vocabularies, to three audiences, and the NOC assembled the story by hand or not at all.
The failure mode at carrier scale is not blindness. It is fragmentation plus volume. Everything is visible somewhere, arriving faster than anyone can read it, in a form that requires a human to join it up.
What the day actually looked like
Root-causing a fault meant hopping between element managers, device by device. Where dashboards existed they showed symptoms, and getting an actual current value out of a device still meant logging into the device. Network faults, server health and service state were monitored, where they were monitored at all, in separate tools with separate truths, so cause and impact were rarely on the same screen.
None of that is unusual. It is what most large estates look like, and it is why the interesting number in this deployment is not a detection metric.
The one pipeline
SNMP traps and metrics, Kafka streams and polled collection from all 27,000 or more devices now land in a single pipeline, normalised and correlated on arrival rather than joined later by a person. Events and KPIs are processed as they arrive, so degradation surfaces in the central layer within moments rather than at the next report cycle. The same layer covers the infrastructure underneath and the services riding on top, which is what puts cause and impact in one place.
Two capabilities changed the texture of a shift more than the architecture did. Sentinel investigates each fault against topology, history and correlated signals, and presents a probable cause with the evidence attached. And NOC users can ask for an actual live value and get it from the estate, rather than opening a session on the device to read it. Those sound small next to a data pipeline. They are the two things engineers noticed first.
The decision that made it deployable
Here is the part a competitor would leave out of a case study, and it is the reason the deployment exists.
That constraint is not a compromise the technology forced. It is the governance model working as intended, and it is the same argument we make in confidence scores are the wrong gate: what decides whether something runs alone is the blast radius of the action, not how sure the system is. In a network carrying live subscriber traffic, the radius of almost everything is wide, so almost everything is a suggestion.
What was measured
| Figure | What it is |
|---|---|
| 27,000+ devices | Estate under one near-real-time fault and performance pane. Countable, not estimated. |
| Three ingestion paths, one pipeline | SNMP, Kafka and polled collection, normalised and correlated on arrival. |
| 43% MTTR reduction | Measured in production within six months of go-live, against the documented pre-deployment baseline. |
| 85% of routine manual operations automated | Measured in production, running as governed MOPs with audit and rollback. |
| ~60% of incidents auto-created with context | Raised by the platform carrying probable cause and evidence, rather than as a bare alarm. |
All five are from this one deployment. We do not put them next to figures from our other customers, and the reasoning for that rule, including the time we broke it, is in how we decide what to publish as a number. The case study itself is explicit that its MTTR and automation figures are measured production results and that the remaining improvement figures in it are indicative.
Where the 43 percent came from
Not from repairing faster. Almost nothing in this deployment repairs faster than a competent engineer already did. What disappeared was the manual archaeology: the hop between element managers, the search for which of three pipelines held the relevant signal, the session opened on a device to read a value the platform could have answered. That is detection and investigation latency, and in most estates it is the majority of mean time to restore. We set the general case out in your MTTR is mostly waiting; this is the same shape with a number attached.
The full record, including the before-and-after across six dimensions, is in the case study. The other two deployments in this series are a North America telecom closed loop and a North America enterprise patching estate, and they are different customers with their own numbers.
Frequently asked questions
Which deployment do these numbers come from?
One: a Tier-1 telecom operator in India, with an estate of more than 27,000 routers, switches and devices. The 43 percent MTTR reduction was measured in production within six months of go-live against the documented pre-deployment baseline, and the 85 percent routine-operations figure was measured in the same deployment. We do not stack these next to figures from our other customers, and the case study states which of its own numbers are indicative rather than measured.
Why does Sentinel only suggest root causes here?
Because that is the scope the operator granted, and granting it that way is why the deployment happened. Autonomy is earned scope by scope. Execution is limited to predefined, approved MOPs, and everything outside that set is a suggestion with evidence attached for an engineer to act on. A vendor who tells a carrier NOC that the AI will decide on its own judgement from day one does not get a second meeting.
What does 43 percent MTTR reduction actually measure?
Mean time to restore across the incidents the NOC handled, after go-live, against the operator baseline recorded before deployment. It is not a per-incident best case and it is not a projection. Most of the improvement came from removing the manual archaeology stage, not from fixing faster, which matches what we see everywhere: the repair was rarely the long part.
Does this require replacing our existing collection?
No. The three ingestion paths in this deployment, SNMP traps and metrics, Kafka event streams and poll-based collection, all continued to run. What changed is that they landed in one pipeline and were normalised and correlated on arrival, rather than each staying in its own silo with its own truth.