What does managed network monitoring cover?

Managed network monitoring normally covers the collection, interpretation and review of technical data from the network components that have been included in the service. Its purpose is not simply to show whether equipment is switched on; it establishes what is normal, identifies deviations that need attention and provides evidence for diagnosing network issues.

The exact scope depends on the managed service agreement and the systems connected to the monitoring platform. A well-defined service will usually specify which sites, devices, links and supporting systems are included, what information is collected, which conditions generate alerts and how those alerts are assessed.

• Devices and infrastructure: Monitoring may cover routers, switches, firewalls, wireless controllers, access points, virtual network appliances and other infrastructure that supports business connectivity. The service may check operational status, interface conditions, configuration state, resource utilisation, error messages and communication between dependent components.
• Network links: A monitoring service can examine the condition of internet connections, site-to-site links and private circuits. This may include link availability, packet loss, latency, fluctuating performance and changes in connection quality. These checks help distinguish a problem within the local network from an issue affecting an external connection.
• Traffic and utilisation patterns: Monitoring tools can record how network resources are being used over time. Sustained increases, unusual peaks or changes in traffic distribution may indicate legitimate business growth, a misconfigured system, an application problem or activity that warrants security investigation. Trends are generally more useful than a single reading because they provide context for decisions about upgrades and configuration changes.
• Event and log information: Network equipment generates records about interface errors, authentication attempts, configuration changes, failed connections and other operational events. Bringing relevant records together can make it easier to identify relationships between separate symptoms, such as a device error followed by loss of access to a business application.
• Alert rules and prioritisation: Monitoring is configured around thresholds, patterns and conditions that indicate a material issue. Rules may distinguish between an informational event, a condition requiring investigation and a fault that needs escalation. Good alert design avoids treating every technical warning as an emergency while still highlighting events that could affect users or expose the network to risk.
• Security-related indicators: Network monitoring may identify unusual connection patterns, repeated failed access attempts, unexpected configuration changes, suspicious traffic destinations or devices appearing where they are not expected. This provides useful detection information, but it is not automatically the same as a complete managed cyber security service. The agreement should state whether investigation, containment, endpoint protection and incident response are included separately.
• Baseline comparison: A baseline describes normal behaviour for a particular environment, site or period. Comparing current information with that baseline helps identify gradual deterioration and unusual changes that fixed thresholds might miss. Baselines should be reviewed when the organisation adds users, locations, applications or new types of network equipment.
• Dependency awareness: A network fault can have several related symptoms. For example, a failed upstream connection may cause multiple devices and services to appear unavailable. Monitoring should correlate related events where possible so that investigation focuses on the likely underlying cause rather than treating every resulting alert as a separate incident.
• Trend and capacity information: Historical monitoring data can support decisions about bandwidth, equipment resources, wireless coverage and site expansion. It can show whether an issue is isolated or part of a continuing pattern. This information is particularly useful when planning changes, because it provides an evidence base rather than relying only on occasional user reports.
• Records and reporting: A managed service may retain alert history, investigation notes, performance trends and actions taken. Reports can summarise recurring issues, unresolved risks, configuration concerns and recommendations for further work. The useful content of a report is not just a list of alerts; it is an explanation of their significance and any agreed follow-up.

Monitoring also has boundaries. It may not cover personally owned equipment, unmanaged switches, home networks, third-party applications or devices that have not been supplied with the information needed for monitoring. A device can also appear healthy while users experience an application, identity or service-provider problem. For that reason, network monitoring should be considered one part of wider IT management rather than a replacement for service desk investigation, security controls or regular technical reviews.

Before agreeing a service, a business should confirm the monitored assets, sites and connections; the data sources used; alert severity definitions; escalation ownership; retention of records; reporting arrangements; maintenance of monitoring agents or credentials; and the process for adding or removing equipment. It should also establish which actions the provider may take automatically and which require approval from the business.

For an organisation using S2 Technology Group for managed network services, these scope and responsibility questions should be documented alongside the wider network service agreement. Clear boundaries ensure that monitoring data can be interpreted correctly and that the business understands what the service covers, what remains its responsibility and when a separate cyber security or infrastructure service is needed.