Network Performance Monitoring
Network Monitoring Tools are not alike! In fact, no network monitoring is equal for many reasons, where you are monitoring traffic make a massive difference to what you see and therefore what your user actually sees, but that is more about traffic and speed or network performance monitoring.
This article is about everything network monitoring tools should be, and will focus on what a small network (sub 50 users) monitoring tool should provide.
Network Performance Monitor
Where you measure network performance can distort what users are experiencing. Lets look at an example:
A user reports their Internet connection is slow, you check with other users and they seem fine, no need to check the router then, but you do for completeness and sure enough the connection is near the expected maximum speed down and up to the ISP.
Could this be something to do with the users computer performance, application performance monitoring can show many things but the most obvious can be seen by looking at the users screen and the Task Manager, they are using Chrome to browse the internet and so Task Manager shows 20 associated tasks while chrome shows 9 tabs open. The user isn't downloading anything and closing the browser and using just one new tab doesn't improve performance. There are no updates going on either.
This might be about data flow or something simpler. You open a command prompt and ping the router, sure enough, you are dropping packets and the ping times are high for a local connection.
So what could you have done?
Lets look at what you would have seen immediately in a Network Monitoring Tool like Angsteps Netmon.
Simple Network Management
Netmon uses a single agent that is typically placed on a computer or server that is running on the network 24/7. It automatically identifies a device on that Local Area Network (LAN), it shows the results of ping tests, latency etc. If the user in our example was being monitored by Netmon you would have seen poor ping results and high latency immediately which would have narrowed the fault diagnosis to a cable, links to a switch or the router or perhaps the users network card.
Key network performance
Each device discovered has it's own card with easy to see:
- * Device name
- * IP Address
- * MAC address
- * Device Type
- * Vendor
- * Packet Loss
- * Latency
- * and Commonly open ports
Real Time? Not quite
The display is updated every 30 seconds with the results of scans displayed in a standard format. This makes real network traffic issues easy to identify, especially if you also use the Topography page to look at the connected layout of devices.
Security Vulnerabilities
On it's own page you will discover a list of potential CVE issies with devices, by utilising this list you are able to check that key updates have been performed to ensure devices are not points of failure. The drill down list enables you to identify the root issue and comment in the status box and to resolve the issue when the fix has been applied.
Vulnerability management starts with asset truth
A vulnerability scan is only as reliable as the asset list behind it. If a laptop has been replaced, a rogue device has appeared on the network, or a server has changed IP address, a scan based on yesterday’s spreadsheet will create blind spots and false confidence.
For an MSP, asset discovery is not an annual housekeeping exercise. It needs to be continuous. Every device seen on a client network should have a clear identity, operating system detail where available, network location and ownership context. Unknown devices should not quietly become part of the furniture. They need investigation, classification or removal.
This is why monitoring and vulnerability scanning should work from the same live view of the estate. When discovery, device monitoring and exposure data are separated, technicians spend time reconciling records before they can decide whether an alert matters. A unified view cuts that delay. It also helps service delivery managers trust the numbers used in client reviews.
There is a trade-off. Broad discovery can surface devices that are not in scope for management, such as personal phones, printers supplied by a landlord or specialist equipment managed by a third party. That does not mean they should be ignored. It means they need to be labelled correctly, assigned an owner and treated according to an agreed risk policy.
What effective vulnerability management looks like
Good vulnerability management is a lifecycle, not a monthly scan followed by a long PDF. It joins discovery, assessment, prioritisation, remediation and evidence into one operational rhythm.
Match vulnerabilities to real exposure
A CVE reference alone does not tell a technician what to do next. The useful question is whether that vulnerability applies to a specific device, version and service in a real client environment. Security intelligence should connect discovered software and operating systems to known CVEs, then add context around severity and active exploitation.
Actively exploited vulnerabilities deserve a different response from a theoretical issue on an isolated, non-critical device. That does not mean a high CVSS score can be dismissed, but it does mean prioritisation should reflect the likelihood and impact of compromise. An internet-facing server with a known exploited flaw is not comparable to a low-use internal workstation awaiting a planned replacement.
MSPs should also consider compensating controls. Network segmentation, disabled services, endpoint protection and restricted access may lower immediate risk, but they are not a reason to leave a vulnerability open indefinitely. Record the control, set a review date and make the residual risk visible.
Prioritise work that changes the risk position
A long list of findings creates activity, not necessarily security. Technicians need a queue that answers: what should we fix first, what can wait for the next maintenance window, and what requires a client decision?
A practical priority model combines exploit status, severity, asset criticality, exposure and remediation availability. A critical flaw on a domain controller, for example, should rise above a similarly scored issue on a retired but powered-down test machine. Equally, a medium-severity vulnerability on hundreds of endpoints may justify attention because its cumulative operational risk is high.
This approach protects technician time. It also makes conversations with clients more credible. Rather than presenting an intimidating list of hundreds of CVEs, an MSP can explain that three issues require action this week, ten are scheduled under patch policy, and the remaining findings are accepted or monitored with documented reasons.
Make remediation accountable
Finding a vulnerability is the easy part. Closing it without disrupting a client’s operations is where managed services earn their keep. Patches may need a maintenance window, a line-of-business application may require compatibility testing, and firmware updates can carry their own risk.
Each material finding should have an owner, a target date and a clear status. Where the fix is straightforward, remote access and device context should be close at hand so the technician is not moving between separate tools to investigate, connect and update records. Where remediation depends on the client, the issue should become a visible decision rather than an unanswered email.
Risk acknowledgement is particularly valuable here. Some clients will choose to defer a patch because of operational constraints. That can be reasonable, provided the decision is explicit: the affected asset, the business reason, the residual risk, the agreed mitigating controls and the review date should all be recorded. Silent acceptance is not risk management.
Build a service cadence, not a reporting scramble
The strongest MSP vulnerability management programmes run on a predictable cadence. Continuous discovery and regular scanning supply the data. Daily or weekly triage deals with urgent exposure. Monthly operational reviews address outstanding remediation. Quarterly client reports show risk movement and decisions made.
This does not require every client to receive the same service level. A small professional-services firm and a regulated business with public-facing systems will have different risk appetites, maintenance windows and reporting needs. Standardise the process, then tune the thresholds and response commitments per client agreement.
The report itself matters. A technical export may satisfy an engineer, but it does little for a managing director deciding whether to approve an upgrade or accept a risk. Plain-English reporting should show the direction of travel: new critical findings, remediated issues, ageing exceptions, unmanaged or rogue devices and decisions awaiting approval.
A useful client report answers four practical questions:
- * What was discovered and monitored during the period?
- * What vulnerabilities created the greatest exposure?
- * What actions did the MSP complete or schedule?
- * What decisions or investment are now required from the client?
That is how invisible security work becomes a visible managed-service outcome. It shifts the conversation away from “what are we paying for?” and towards “what risk did we reduce this month?”
Avoid the tool-sprawl trap
Many MSPs already own the components of a vulnerability management process. They have a monitoring platform, a remote-control tool, a scanner, an asset spreadsheet and a reporting template. The problem is the hand-off between them. Every hand-off adds duplicate data, lost context and technician effort.
A consolidated platform can remove much of that friction when it combines live discovery, monitoring, CVE matching, remote access, rogue-device detection and client reporting in one multi-tenant workspace. With one agent per site and clearly separated client environments, the operational view stays practical rather than becoming another administration burden. Angstep Netmon is built around that model, giving MSP teams a single place to move from finding to investigation, remediation and evidence.
Consolidation is not automatically the right answer in every case. Some MSPs have contractual requirements for a specialist scanner, a mature SIEM workflow or an established RMM that cannot be replaced quickly. The sensible first step is to identify where technicians lose time and where evidence disappears. If the answer is repeated asset reconciliation and manual reporting, integration or consolidation should be a priority.
Measure the work that clients cannot see
Closed vulnerabilities are useful, but they are not the only measure of programme health. Track how quickly critical findings are triaged, how long high-risk issues remain open, how many devices are unmanaged, and how many risks are awaiting client acknowledgement. These measures reveal whether the process is improving or merely producing more findings.
Most importantly, measure risk reduction by client. A downward trend in critical exposure, fewer unknown devices and faster remediation tells a story a board can understand. It also gives account managers a fact-based reason to discuss upgrades, replacement projects and security investment before a weak point becomes an incident.
The next time a serious CVE lands, the goal is not to prove that your scanner received it. The goal is to show, within minutes, which clients are affected, what action is underway and what evidence will be ready for the next service review.
Network monitoring is an MSP operating system
Traditional monitoring is often treated as a reactive function. A host goes down, a threshold is crossed, a ticket appears, and someone investigates. That remains necessary, but it is too narrow for the way MSPs now deliver services.
Client networks change constantly. Employees bring in unmanaged devices. A router is replaced without being documented. A switch port becomes overloaded. A vulnerability is disclosed against software that may be sitting on a forgotten server. Each change can affect performance, security and the accuracy of the client asset record.
A useful monitoring platform therefore needs to answer three practical questions at once: what is on the network, what is happening to it now, and what requires action? When the answers live in separate products, the technician becomes the integration layer. That is expensive, inconsistent and hard to scale across dozens of client environments.
The better model is a single operational workspace with clear multi-tenant separation. Each client remains isolated, but the service desk can move quickly from an alert to the affected device, its services, its exposure and an appropriate remote session. This is not about having one dashboard for its own sake. It is about reducing the time between signal and decision.
What MSP network monitoring must show
A green status icon is not enough. It can hide the distinction between a healthy network and a network that is merely still answering a ping. MSPs need depth, but they also need it presented in a way that supports fast triage.
At a minimum, live visibility should cover device availability alongside latency, packet loss, interface status and key service checks. These indicators help a technician separate a genuine site-wide fault from a local Wi-Fi complaint, an internet-provider issue or a problem isolated to one machine.
Continuous discovery matters just as much. Static asset lists decay quickly, particularly in smaller client businesses where hardware purchases and office changes are not always reported to IT. A platform that sees new devices as they appear gives the MSP a chance to validate them before they become an unmanaged access point, a personal printer with weak security or an unknown endpoint on a sensitive VLAN.
Security context must sit beside operational context. A device name and IP address do not tell a technician whether an exposed service is a concern, or whether installed software maps to a known CVE. Matching assets against vulnerabilities and actively exploited threats helps teams prioritise the work that carries real risk, rather than treating every finding as equally urgent.
This does not mean every detected vulnerability demands an immediate patch. A legacy application may be business-critical, a fix may require a maintenance window, or a client may accept a defined risk while a replacement is planned. The key is to record the decision, the owner and the review date. Risk acknowledgement turns an awkward email trail into an accountable security workflow.
One agent per site changes the economics
Many MSP tool stacks create friction before monitoring has even begun. Agents must be installed, maintained and licenced across endpoints. Separate scanners need credentials and schedules. Remote access is managed elsewhere. Reporting relies on exported data and manual interpretation.
A single-agent-per-site approach removes much of that overhead. It can discover connected devices, collect monitoring data and support controlled access without demanding a separate deployment on every networked asset. That is especially valuable for switches, printers, NAS devices, firewalls, cameras and other equipment that cannot run a conventional endpoint agent.
There are trade-offs. An agentless or site-agent model will not replace detailed endpoint telemetry where deep operating-system control is required. MSPs supporting highly regulated clients, complex server estates or specialised compliance requirements may still need additional tools. The point is not to force every function into one product. It is to stop buying separate products for work that one well-designed platform can perform.
For typical small and mid-sized client environments, the gain is substantial. Onboarding becomes faster, the asset picture becomes more complete, and technicians spend less time keeping the toolset itself alive. Those hours can be redirected towards remediation, service improvement and client-facing advice.
Turn alerts into a deliberate service workflow
The difference between useful alerts and alert fatigue is not simply the number of notifications. It is whether each event arrives with enough context to guide the next action.
A device-down alert should lead directly to its recent status, network location, affected services and remote-access options. A newly discovered device should trigger validation, classification and an ownership decision. A vulnerability finding should show the asset, severity, available remediation and whether the issue has been acknowledged by the client.
That creates a more disciplined workflow:
- * detect changes, outages and exposure across every managed site;
- *investigate from one client-specific view rather than switching portals;
- *act through remote access, remediation or a documented escalation;
- *record the outcome so the next technician and the next client review have the full story.
Live refresh intervals matter here. Data that updates every 30 seconds supports active fault-finding. A once-daily scan may be sufficient for some compliance checks, but it will not help when a client is waiting for an answer during a working day. Match the monitoring frequency to the service promise you have sold.
It is also worth setting thresholds per client rather than applying generic rules everywhere. A brief latency spike may be irrelevant at a small office with a resilient connection, but unacceptable for a practice relying on cloud telephony. Standardisation is valuable, yet good MSP service still accounts for the client’s operational dependency on IT.
Reporting is where invisible work becomes retention
Technical teams often know exactly what they have prevented: the rogue device caught at discovery, the risky software identified before exploitation, the recurring packet loss traced to a failing link. Clients rarely see that work unless it is translated into a clear report.
A branded PDF report should not be a dump of alert counts and CVSS scores. Non-technical decision-makers need a plain-English account of the current estate, key security concerns, actions completed and decisions requiring their input. They need to understand whether the business is becoming safer and more stable, not decode a spreadsheet of IP addresses.
That does not require hiding technical detail. Include it where the IT contact needs it, but lead with the business meaning. For example, explain that unsupported software creates a higher chance of disruption or data exposure, then show the affected devices and agreed next steps. Explain that unmanaged devices have been found, then state whether they were authorised, isolated or removed.
This is commercially important. A client review built around live infrastructure data and documented remediation demonstrates an active service. It moves the conversation away from, “What have we had for our monthly fee?” and towards, “What should we improve next?”
Angstep Netmon brings discovery, monitoring, vulnerability and exposure intelligence, remote access and client reporting into that same multi-tenant workflow. The practical outcome is fewer hand-offs between tools and a stronger evidence trail for every client relationship.
Build monitoring around decisions, not dashboards
Adding another screen rarely fixes tool fatigue. The test is whether your monitoring setup lets a technician make a sound decision without hunting for missing context. Can they identify an unknown device, assess its risk, reach the right system and document the result without stitching together five products? Can a service delivery manager see where risk is accumulating across clients? Can an account manager explain the work in language a director will act on?
If the answer is no, the gap is not merely technical. It affects response times, margins and retention. Start by mapping the moments where your team leaves one tool to find the information needed in another. Those hand-offs are usually where monitoring work becomes slow, inconsistent and difficult to prove.
The best next step is not a larger alert queue. It is a clearer view of the client environment, connected to a workflow that turns every meaningful signal into action the client can see.
Bio for Stephen Richards: Born in Colwyn Bay North Wales, Steve's introduction it Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week!
Steve left School in 1976 joining the Royal Air Force to work on RADAR and communications equipment. His last 5 years involved working in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE.
During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!
Leaving the RAF after 18 years service Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team with his last project moving email from a Linux Box to Microsoft Exchange for the 300 users in the company each of whom typically had 5 email addresses.
In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions was an MSP and moved to become an MSSP following another of Steve's passions Cybersecurity. Officially retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.
By August 2026 two significant pieces of software have been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks..... And so it begins!
