Link and reachability
The internet circuit, inter-branch tunnels and critical devices are polled at short intervals. When a link drops, the alert fires before anyone reaches for the phone.
Service detail
Network Monitoring and Ongoing Management
The system reports the fault, not the user. Measurement, thresholds, alerting and a monthly report run together.
We start with a simple question: when the internet goes down, who notices first? If the answer is "when a user complains", that organisation has no network monitoring. Outage duration is usually imagined as repair time, yet in the field most of the lost time is not spent repairing anything — it is spent before anyone realises there is a problem. A circuit that fails at nine, is noticed at eleven and fixed by half past eleven costs two and a half hours, and two of those hours are pure ignorance.
Network monitoring closes that gap. Devices, circuits and critical services are measured continuously, and when a value leaves its threshold the alert lands on a predefined address. Ongoing network management is the monthly service built on top of it: rule review, firmware schedule, configuration backup, inventory, change log and reporting. The two look like separate line items but only make sense together — management without measurement becomes guesswork, and measurement without management becomes a dashboard nobody opens.
What gets measured
A device being up is not the same as working
A server that answers a probe may be running an application that has already crashed. Metrics are chosen to see that difference.
Bandwidth saturation
Inbound and outbound traffic are measured separately. Saturation is the most common cause of slowness, and a circuit approaching ninety percent is visible long before it stops passing traffic.
Interface error counters
Dropped packets, CRC errors, collisions and interfaces that keep flapping. These counters announce a failing cable or port well before it causes an outage.
Device temperature and fans
In a cabinet with failing ventilation a switch first heats up, then shuts itself down. The temperature curve explains most of those night-time outages nobody can account for.
CPU and memory
Sustained high CPU on a firewall means the rule set or the inspection load needs review. Memory exhaustion is the last warning before a device reboots itself.
Service reachability
A device being up does not mean the service is running. Name resolution, file server, mail and the line-of-business application are each probed with a real request.
Certificate and domain expiry
An expired certificate produces a service outage without any attack involved. Days remaining are tracked and the alert fires weeks ahead of the deadline.
Wireless health
Clients per access point, signal levels and reconnection frequency. Behind a dropping wireless complaint there is usually capacity or channel overlap, not a faulty device.
Threshold design
The hard part is not collecting data, it is setting the threshold
Collecting is easy; deciding which value should alert, and when, is not. Badly set thresholds hurt in both directions: too sensitive and the setup produces noise, too loose and it reports after the user already has.
- The alert must fire before a user notices. A system that reports after the link is already down is record keeping, not monitoring.
- Saturation thresholds sit below full capacity, not at it; a circuit reaching ninety percent is visible before it chokes, leaving time to act.
- Momentary spikes are separated from sustained conditions. A thirty-second peak should not alert; the same load lasting ten minutes should.
- A noisy alert is an ignored alert. In a setup that sends forty notifications a day nobody reads the forty-first, which is why thresholds get pruned.
- Alerts are graded: informational record, needs review, and act now. Each grade travels on its own channel.
- When an upstream device fails, the dozens of devices behind it are prevented from alerting individually; the root cause arrives as a single notification.
What ends the argument
When somebody says "the internet is slow"
That sentence is heard in every organisation, and without measurement the same scene plays out every time. IT says the circuit is fine, the user insists the slowness is real, finance suspects the application, and the provider reports no fault on their side. Nobody is lying; nobody has data either. The meeting ends with whoever speaks loudest being treated as correct.
With measurement in place the argument closes in minutes. You look at the utilisation graph for the hour the complaint arrived. If the circuit was full, the problem is bandwidth — and the same graph shows what filled it. If the circuit was quiet, the problem is inside: an error counter climbing on a switch port, an access point carrying far more clients than it should, or slowness confined to a single application. Where application response time is also measured, the network is either cleared outright or pointed at directly.
The real gain here is organisational rather than technical. Measurement replaces opinions with evidence. The moment the problem is separated into circuit, internal network or application, the conversation starts with the right party; a ticket raised with the provider carries concrete data and does not close with "no fault found". Equally, when the culprit turns out to be an internal cable or port, nobody wastes a week arguing with the provider.
Capacity planning
Investment decisions come from trends, not complaints
Network spending usually happens at one of two extremes: in a hurry and expensively because work has stopped, or unnecessarily because it felt prudent. Both come from the same cause — there is no historical data. Monitoring opens a third path: trend data.
The bandwidth decision rests not on instantaneous speed but on how peak hours have moved over the past six months. A circuit sitting at seventy percent at midday, read together with its monthly growth, shows the month it will saturate. That means a conversation with the provider before the renewal date rather than after the incident.
The same logic applies to switch ports. How many are in use, how many have sat idle for years, and which cabinet the latest desk moves are straining all show up in the port utilisation report. Whether a new switch is needed, or whether free ports on an existing device can be reached with a different layout, becomes a decision based on numbers.
On the wireless side the numbers that matter are clients per access point and the traffic passing through it. If the single access point in the meeting room climbs to thirty clients every Tuesday morning, the device is not faulty — it is full, and the answer is a second access point rather than a replacement. Without measurement that distinction cannot be made, and the wrong device usually gets swapped.
Ongoing management scope
What the monthly service covers
Monitoring sees the problem; ongoing management covers the work that keeps it from returning.
Periodic rule review
Firewall rules accumulate. Who asked for it, on what date, is it still needed. Unused and shadowed rules are closed at the end of each review period.
Firmware and patch schedule
Firmware updates run on a plan. Which device is on which version, which update is being held back and why — all in writing. Critical security patches leave the schedule.
Configuration backup
Router and switch configurations are captured regularly and kept in version control. The before and after diff is visible, and a bad rule is reverted in minutes.
Inventory accuracy
Which device sits where, with what serial, when the warranty ends, on which port. In a network with a stale inventory, fault duration doubles.
Change log
Every intervention is recorded with who, when and why. The reason a network worked yesterday and does not today is usually written in that log.
Monthly report
Outage durations, alert counts, the busiest circuits and ports, approaching capacity limits. The report is written to be decided on, not to be decoded.
Incident handling
What happens after the alert fires
An alert is worth something only when the steps behind it are written down. An alert with no defined owner is a notification nobody looks at.
- 1 The alert lands on a predefined channel; who sees it is never left to chance. Separate destinations are defined for business hours and out of hours.
- 2 First response establishes scope: one user, one segment, or the whole network. Every step taken before that distinction is guesswork.
- 3 The affected side is told what is happening. If the duration is unknown, that is what gets said; silence is the worst option.
- 4 Workaround and fix are kept distinct. Failing over to the backup circuit restores service but does not close the fault.
- 5 An incident record is kept: when it started, when it was noticed, when it closed. Time to notice is the report card of the monitoring itself.
- 6 A post-incident note is written: what happened, how long it lasted, what was done so it does not recur. The incident is not closed until the third question is answered.
Process
Five stages from setup to reporting
The first two weeks are observation; abnormal cannot be defined before normal is known.
- 01
Inventory and Access
Which devices get monitored, over which protocol, with which privileges. Monitoring accounts are read-only; the monitoring system must not become a new attack surface.
- 02
Choosing the Metrics
Not everything is collected from every device. Metrics that carry business meaning are selected; meaningless data is the noise that hides the real alert.
- 03
Threshold and Alert Design
The first two weeks are observation. Abnormal cannot be defined before normal is known. Thresholds follow that baseline and stay adjustable afterwards.
- 04
Incident Flow
Who receives an alert, on which channel, at which severity — all written down. The out-of-hours path is defined separately.
- 05
Reporting and Review
A monthly report and a periodic review. Thresholds producing false alarms get corrected, missing metrics get added.
Commercial model
Fixed monthly fee, scope in writing
Ongoing network management runs on a fixed monthly fee, set by device count, number of locations and the target response time; setup and threshold design appear as a one-off item in the first month. What sits outside the scope is defined with the same clarity: hardware replacement, new site deployments and project-level changes are quoted separately. The most important clause in the contract is not the price but the item-by-item list of what is included and what is not — a vague scope leaves both sides exposed at the first serious outage.
FAQ
Frequently asked
What exactly is monitored?
Link and reachability state, inbound and outbound bandwidth, interface error counters, device temperature, CPU and memory, reachability of critical services probed with a real request, certificate expiry, and on the wireless side clients per access point along with signal levels. Scope is agreed during setup; collecting every metric from every device produces noise rather than value.
Who receives the alerts, and can we see them too?
Alerts reach us and first response starts on our side. If you nominate someone internally, the same notification goes to them as well. Channels can be split by severity: informational records as a daily digest, act-now items as an immediate notification. A separate flow is defined for out of hours.
How many devices can you monitor?
The same approach applies from a small office with a handful of devices to a multi-branch estate with hundreds. The limit has less to do with device count than with polling frequency and retention. Above roughly a hundred devices we agree on the collection point and the retention plan up front, otherwise the monitoring system itself becomes a maintenance item.
We already have a monitoring tool. Can you use it?
Usually yes. We look at what the existing setup actually collects and whether anyone reads the alerts. The most common situation we find in the field is a tool that is installed and running while its alerts have gone to nobody for years. Fixing the thresholds and the alert flow of such a system is normally faster and cheaper than rebuilding it.
How often does the report arrive and what is in it?
The standard monthly report covers outage durations, alert counts and their distribution, the busiest circuits and switch ports, approaching capacity limits, changes made during the period and any open items. Critical events also get their own incident note. The report is written as a document you can decide on, not as a technical dump.
How quickly do you respond to a fault?
Response time is written into the contract and varies by severity. An outage affecting the whole organisation and a single user reporting slowness are not handled on the same clock. Remote response starts within minutes; where on-site attendance is needed we attend the same day around Alanya and Antalya, and work remotely — with local coordination where required — across Turkey.
Does monitoring send our data outside?
Monitoring data consists of counters and state; the content of user traffic is never read. On request the collector runs on a server inside your building, in which case the data never leaves the premises. Where outside access is required, it is defined as read-only and logged.
How does pricing work?
Ongoing management runs on a fixed monthly fee set by device count, number of locations and the target response time. Setup and threshold design appear as a one-off item in the first month. Hardware replacement and project work sit outside the scope and are quoted separately. What is included and what is not is listed item by item in the contract.
Related services
Network infrastructure and management →
The parent page covering every network service from design and security to deployment and ongoing management.
Network design and corporate deployment →
IP plan, VLAN scheme, cabling and wireless coverage: a monitorable network is drawn correctly first.
Router and switch configuration →
Routing, VLANs, trunks and port security, with configurations kept in version control.
Outsourced IT support →
Workstations, servers and printers managed from the same desk as the network itself.
Servers and hosting →
Web, application and database hosting brought into the same monitoring and reporting scope.
Ready for your next software project?
Book a free 30-minute discovery call with our team.
