Network operations · Operating since 2002
Most networks fail quietly before they fail loudly. A switch port starts discarding frames, an access point drops to a saturated channel, a backup circuit has been down for eleven days and nobody noticed because the primary was carrying the traffic. None of it pages anyone. All of it surfaces later as “the network is slow”, usually during the week it matters most.
A network operations centre exists to catch the quiet failures. NOC as a Service means that function is run for you — the platform, the probes and the engineers watching them — rather than hired, rostered and tooled in-house. We have run network operations since 2002, and we build the platform we monitor on.
Coverage
What we actually watch
Most “network monitoring” is device up/down and a bandwidth graph. That catches the loud failures and almost none of the quiet ones. Here is the real surface.
Switches, port by port
Not just whether the switch answers. Per-port utilisation, errors, discards, CRC counts, duplex mismatches, PoE draw against budget, and uplink saturation. A failing cable shows up as a rising error counter weeks before anyone files a ticket.
Wireless, including the client side
Access point and controller health, but also channel utilisation, co-channel interference, client count per radio, retry rates and association failures. This is where most user-reported network problems actually originate, and it is the layer most outsourced NOCs skip — the ports look perfect while the users suffer.
Live interface throughput
Real-time per-interface data rates rather than a five-minute average that flattens every burst. Micro-bursts and short saturation events are exactly what break voice and video, and exactly what averaged polling hides.
WAN links and carrier SLA
Utilisation, latency, jitter and packet loss per circuit, measured continuously — so when a carrier insists the link is clean, the evidence exists. Backup circuit state is tested rather than assumed.
Routers, firewalls and gateways
Interface state, CPU and memory pressure, session counts, tunnel and BGP peer state, and failover events as they happen rather than in the following morning’s report.
Servers, virtualisation and cloud
Reachability, resource pressure and service state, plus cloud network telemetry wherever the provider’s API exposes it.
Architecture
A probe at every site, not one collector polling the world
We place a probe at each location rather than polling every remote device across the WAN from a single central collector. That sounds like an implementation detail. It decides whether you can diagnose an outage or only observe one.
The site that goes dark
Central-only polling loses visibility at exactly the moment you need it most, and reports a single alarm — site unreachable — for what might be a carrier fault, a power event or a failed edge device. A local probe keeps recording throughout and syncs the timeline when the link returns.
The failure is identical either way. Only the instrumentation differs, and with it your ability to tell the carrier what actually happened.
Two effects people miss
Polling can be frequent. Sub-minute intervals across a large estate are practical when the traffic stays on the LAN, and impractical when every poll crosses the WAN.
Your WAN stops carrying monitoring traffic. On thin branch circuits, centrally polling a full site consumes a measurable share of the bandwidth the monitoring exists to protect.
The platform
The monitoring platform is included, not rebilled
Almost every NOC-as-a-Service provider resells someone else’s monitoring platform and rebills you per device, per sensor or per node. As your estate grows, so does that line item — and the provider’s margin grows with it. You end up paying twice for the same switch: once in the licence, once in the service.
We built ours. PrahiX Ora Sustain is our own network monitoring platform, and it is part of the service rather than a line item beside it.
No per-device licence
Adding twelve access points to a branch is a configuration change, not a purchase order. Your monitoring cost stops tracking your device count.
Multi-tenant by design
Hard separation between environments, which is what makes the MSP arrangement below workable rather than a promise.
Custom collectors
When a device speaks something unusual — an OLT, a UPS, an environmental sensor, a vendor API with no standard MIB — we extend the collector rather than telling you it is out of scope.
If you would rather keep your own platform, we will run yours. Co-managed engagements on customer-owned tooling are routine, and the section below covers how they are usually split. The wider platform, including SIEM, SOAR and video analytics, sits alongside the monitoring module.
The comparison
In-house, outsourced, co-managed, tool-only
Five ways to cover the same requirement, with the honest limitation of each — the column most comparison charts leave out.
Scroll the table sideways →
| Model | Who is watching at 03:00 | Monitoring platform | Staff you carry | Best fit | The honest limitation |
|---|---|---|---|---|---|
| In-house NOC | Your engineers, on a rota | You buy, run and upgrade it | 6–8 FTE for genuine 24/7 | Large estates with the scale to justify a full rota | The rota is the cost. Holidays, resignations and sickness all land on the same small team. |
| NOC as a Servicethis page | Our floor, continuously | Included — no per-device licence | None | Multi-site estates with a lean internal team | You are trusting an outside team with visibility. That is only safe if the escalation matrix is written down. |
| Co-managed NOC | Us at night and weekends, you by day | Yours or ours | Your day shift only | A strong day team with no night cover | Highest coordination overhead. Gaps open at the handover if the runbook is vague. |
| Tool-onlyan NPM platform | Nobody — alerts queue until morning | You license it per device or per sensor | Every shift you want covered | Teams who have the people and only lack visibility | The platform detects the fault correctly at 02:40 and writes it to a dashboard nobody is looking at. |
| Break-fix / reactive | Nobody, until a user calls | Minimal | None | Single sites with low dependency on uptime | Every fault is discovered by the people it is hurting, which is the most expensive way to find one. |
The row that surprises people is the fourth. Buying a monitoring platform is routinely mistaken for buying monitoring — and the platform will detect the fault correctly at 02:40 and write it to a dashboard nobody is looking at. Detection with no human attached is a record of what went wrong, not a response to it.
Money
The arithmetic of 24/7
Why continuous cover needs five people
Continuous coverage is 8,760 hours a year. A full-time engineer, after leave, public holidays, training and sickness, delivers roughly 1,900 productive hours.
That is 8,760 ÷ 1,900 ≈ 4.6 FTE — and only to have exactly one person awake at any moment, with no second pair of eyes, no cover for two simultaneous incidents and no redundancy when somebody resigns. Two-deep cover across all shifts lands closer to six or eight.
The figure is the same for every organisation, because it is arithmetic rather than opinion. What differs is whether those engineers are yours alone or shared across a floor that runs continuously anyway.
What drives the price
We publish the drivers rather than a starting figure, because a monthly number without a scope is meaningless:
- Monitored device count, and the split between network, server and cloud
- Number of sites, and therefore probes
- Coverage hours: 8×5, 24×5, or 24x7x365
- Whether wireless and cloud telemetry are in scope
- Escalation depth — notify only, or act within an agreed change boundary
- Reporting and review cadence
Note what is not on that list: a per-device platform licence. Ask every provider you shortlist whether they can say the same.
The staffing figures are arithmetic on the assumptions stated above rather than a published benchmark. Change the working week or the leave entitlement to your own terms and the conclusion barely moves.
Engagement shapes
Co-managed: nights and weekends only
Full outsourcing is not the only shape, and it is rarely the first step. The most common engagement we run is narrower and much easier to approve: your team keeps the day, we take the hours they should not be awake for.
You keep ownership
Your engineers retain the tooling, the architecture decisions and business-hours control. Nothing about the day changes.
We take the hard hours
Nights, weekends and public holidays — the shifts that are hardest to staff internally and the ones that burn people out fastest.
Escalation on your terms
We wake your on-call only against criteria your team wrote. Everything below that threshold waits for the morning handover.
It also works as an evaluation. A quarter of night cover tells you more about a provider than any reference call, and it does not require restructuring your team to find out.
For MSPs
White-label NOC, behind your brand
If you are a managed service provider, the arithmetic above is your problem multiplied by every client you serve. Your engineers are worth more on project work than on overnight dashboards, and a night shift is hard to justify per client.
Multi-tenant, hard separation
One console for you, isolated data per client. The separation is architectural rather than a permissions setting.
Your brand on the reports
Client-facing reporting carries your identity. We are not in the room and we do not need to be.
No licence stacking
Per-device platform licensing across a whole client base is where the tool-resale model becomes unaffordable at scale. Ours does not meter that way.
Tickets in your PSA
Alerts arrive through your PSA or ticketing API, in the workflow your technicians already use, rather than in a console they have to remember to check.
Complementary hours
Most MSP engagements are nights, weekends and holidays only — filling the gap rather than duplicating cover you already pay for.
We do not compete for your clients
Not as a matter of policy and not as a matter of how we sell. If this needs to be contractual for you, say so and it will be.
Straight answers
What “24/7” has to mean
The phrase is on every competitor’s homepage and means very little on its own. These are the questions that separate the claims — ask them of us as readily as of anyone else.
“Is a human awake, or is it an autoresponder?”
Ask what happens to a P1 raised at 03:15 on a public holiday, and whether the first response is a person or a ticket acknowledgement. Both are technically a response within fifteen minutes. Only one of them is any use.
“Response, or resolution?”
An SLA that promises acknowledgement in fifteen minutes and says nothing about what happens next is a promise to notice, not a promise to help. The two numbers are separate contract terms and they are routinely sold as one.
“Is the matrix contractual?”
Severity definitions, response targets in minutes and escalation paths belong in the agreement. If they live in a proposal deck, they are marketing and they will change.
“Who is permitted to act?”
Notification-only monitoring hands you an alert at 3 a.m. and waits for you to wake up. Ask what a provider may change without asking, and make sure that boundary is written down before go-live.
A NOC is not a SOC
A NOC watches availability and performance — up, down, slow, saturated. A SOC watches for attack — intrusion, anomalous authentication, exfiltration. Different alerts, different skills, different people. Providers who blur the two are usually selling one and staffing it with the other.
A platform is not a service
Buying a monitoring platform is often mistaken for buying monitoring. The platform will detect the fault correctly at 02:40 and write it to a dashboard nobody is looking at. Detection with no human attached is a record of what went wrong, not a response to it.
We publish our severity matrix and response targets, and they form part of the agreement rather than the proposal.
Onboarding
The first thirty days
Onboarding is where most monitoring engagements quietly fail. A platform gets deployed, default thresholds fire constantly, everyone stops reading the alerts, and six months later the service is a monthly invoice for noise.
Discovery
We inventory what actually exists, which routinely finds devices nobody remembered and links nobody was paying for.
Probe deployment
One per site, connected and validated against the local estate.
Baseline
Two to three weeks of observation to learn what normal looks like on your estate specifically. Thresholds set before this are guesses.
Threshold tuning
Alerts are tuned against your baseline rather than against vendor defaults. This is the step that decides whether anyone still reads the alerts in month six.
Runbook and escalation
Written with your team: who is called, when, for what, and what we may act on unaided.
Go-live and review
Formal review at 30 days and again at 90, against the alert volumes and response times actually recorded.
Step four is the one to press every provider on. A monitoring service that never tunes is a noise generator with an invoice attached, and alert fatigue is the most common reason these engagements fail.
Before you sign
Ten questions for any NOC provider
Use these on us and on everyone else you shortlist. Several are uncomfortable to answer honestly, which is rather the point.
Who is awake at 03:00 on a public holiday, and where do they physically sit?
Ask for the location and the employer. Subcontracted night cover is common and rarely volunteered.
Is the monitoring platform included, or licensed per device and rebilled to us?
This is the question that changes the five-year cost. A service priced attractively on top of a per-device licence grows with your estate, and the growth is the provider’s margin.
What exactly is monitored — switch ports and wireless clients, or only device up/down?
Up/down monitoring catches the loud failures and almost none of the quiet ones. Ask for the metric list, not the adjective.
How are alert thresholds set, and who tunes them after go-live?
A service that never tunes is a noise generator with an invoice attached. Alert fatigue is the most common way these engagements fail.
What is the escalation matrix by severity, in minutes, and is it contractual?
Severity definitions and response targets belong in the agreement, not in a slide deck.
Is there a probe at each site, and what happens when a site loses its link?
This tends to end the conversation with providers running central-only polling. Without a local probe they go blind at exactly the moment the data matters.
Do you act, or only notify? What may you change without asking us first?
Notification-only monitoring hands you an alert at 3 a.m. and waits. Get the permitted-action list written down before go-live rather than negotiated during an outage.
How does an alert become a ticket in our system?
An alert that lands in the provider’s console and nowhere else is a report you have to go and read.
What arrives monthly, and can we see a real sample report before signing?
Ask every provider you shortlist for a redacted sample. Availability percentages with no incident narrative are decoration.
What do we get back — configurations, historical data, dashboards — and in what format?
Agree exit terms at contract, not at notice. Historical monitoring data is what makes switching expensive.
Working with us
Why buy this from P J Networks
We have run network operations since 2002, for organisations that built their own NOC and for organisations that decided not to. That is the experience this page is written from.
Our own engineers
Fifty-plus in-house NOC and SOC engineers. Ask us who sits on which desk and we will tell you — the same question we suggest you put to everyone you shortlist.
Our own platform
We build PrahiX Ora Sustain rather than reselling someone else’s. The people who ask for features are the engineers on shift at 3 a.m.
Multi-vendor by default
Real estates are mixed. We monitor Fortinet, Cisco, Dell, Palo Alto and Sophos alongside cloud telemetry. See our technology partners.
Certified operations
ISO/IEC 27001:2022 certified, with our operations centre inside the certified scope and the scope statement available on request rather than on assertion.
US presence
P J Networks LLC is our US entity, based in Dallas, Texas — the company a US client contracts with. It is a subsidiary of P J Networks Pvt Ltd, which holds the ISO/IEC 27001:2022 certification referenced on this page.
Questions we get asked
NOC as a Service, answered
What is NOC as a Service?
A network operations centre run for you as a service. The provider supplies the monitoring platform, the engineers and the process; you keep the network. It replaces the need to hire, roster and tool a 24/7 team internally, and it covers the same ground an internal NOC would: availability and performance monitoring, fault detection, escalation, vendor co-ordination and reporting.
What is the difference between a NOC and a SOC?
A NOC watches availability and performance — is it up, is it fast, is it saturated, is it degrading. A SOC watches for attack — is someone in, is this authentication normal, is this traffic exfiltration. The alerts are different, the skills are different and the response is different. Many providers sell one and quietly staff it with the other, so it is worth asking who sits on which desk. We run both, separately, from the same operations floor.
How much do outsourced NOC services cost?
It depends on monitored device count, the number of sites and therefore probes, coverage hours, whether wireless and cloud telemetry are in scope, escalation depth and reporting cadence. The variable that catches most buyers out is the platform licence: many providers price the service attractively and rebill the monitoring platform per device, so the bill grows with the estate. Ours is included, which removes that meter entirely.
Can we keep our existing monitoring tools?
Yes. We run co-managed engagements on customer-owned platforms regularly, and it is the normal arrangement where a contract requires you to hold your own tooling. You lose the licence saving and keep everything else. Expect us to audit the inherited configuration first — platforms that have run without a dedicated team almost always carry thresholds nobody has reviewed in a year and devices that stopped reporting without anyone noticing.
Do you monitor Wi-Fi?
Yes, including the client side: channel utilisation, co-channel interference, client counts per radio, retry rates and association failures, not merely whether the access point is reachable. Most user complaints about “the network” originate in wireless, and a wired-only monitoring stack cannot see any of it — every port reads healthy while the users are suffering.
Do you support MSPs?
Yes, white-label and multi-tenant, with hard data separation between your clients and your brand on client-facing reports. Most MSP engagements cover nights, weekends and public holidays rather than duplicating your own daytime coverage, and alerts arrive as tickets in the PSA your technicians already work in.
Do you need agents installed on our servers?
Not for network monitoring, which uses SNMP, flow data, syslog and vendor APIs. Deeper server and application metrics may use an agent, and that is your decision per host rather than a precondition of the service.
What happens when a remote site loses connectivity?
The local probe keeps polling and recording. When the link returns, we have the interface counters, error rates and wireless data from during the outage rather than a single “site unreachable” alarm. That is usually the difference between diagnosing the cause and guessing at it, and it is the main reason we place a probe at every site rather than polling everything centrally.
Do you fix problems or only report them?
Both, within a boundary agreed before go-live. Some clients want notification only. Others authorise us to act on a defined set of changes without waking anyone. The boundary belongs in the runbook, and it is far better decided calmly in week one than negotiated at 3 a.m. during an outage.
Can we start with nights and weekends only?
Yes, and many engagements begin there. It is the lowest-risk way to evaluate a provider, it addresses the hours that are hardest to staff internally, and it does not require restructuring your team to find out whether the arrangement works. A quarter of night cover tells you more than any reference call.
How quickly do you escalate?
Against a published severity matrix with response targets in minutes, which forms part of the agreement rather than sitting in a proposal. Ask us for it on the first call, and ask everyone else you shortlist for theirs.
How does this integrate with our ticketing?
Alerts raise tickets in your system through its API, so the workflow your team already uses stays the workflow. For MSPs that usually means your PSA.
What is in the monthly report?
Availability and performance by site and by device, capacity trends, incident summaries with root cause, and SLA performance against your carriers. Sample reports are available before you sign — and you should ask every provider you evaluate for one, because this is where the difference between a service and a dashboard becomes obvious.
What happens to our data if we leave?
You receive configurations, historical monitoring data and dashboard definitions in a documented format. Exit terms are agreed at contract rather than at notice.
Next step
Send us your topology, not a requirements document
Tell us how many sites and devices you have and which hours you need covered. We will tell you what we would monitor, what we would not bother monitoring, and what it costs — and if keeping it in-house is the better answer at your size, we will say so.