Your monitoring dashboard is not an outage prevention plan
At 2:14 a.m., your monitoring system reports that a network device is unreachable. Someone acknowledges the alert and opens a ticket. Fifteen minutes later, you receive an email confirming that the device is still unreachable.
That is monitoring followed by notification. It may be exactly what you contracted for. It does not establish that anyone was working to prevent the outage.
The more useful question is what happened during the preceding weeks. Was the device showing a worsening condition? Was there enough evidence to justify an intervention? Did anyone own the decision to act?
Nagios, or any other monitoring platform, can support useful early warning. The gap is not necessarily the software. It is the operating process between collecting a signal and completing a change.
A NOC cannot prevent every outage. Sudden hardware failures and external disruptions still happen. But buyers can distinguish a service that manages detectable risks from one that mostly forwards alerts.
Here is a practical way to make that distinction before signing a contract.
1. Ask for the path from a trend to a completed change
Start with one question:
"Show me an anonymized example, or a worked demonstration, where monitoring identified a developing problem and someone completed a change before service was affected."
You are looking for a chain of evidence:
Observation -> investigation -> recommendation -> owner -> change -> verification
A dashboard screenshot establishes only the first step.
For a hypothetical capacity issue, that chain might look like this:
- A link's busy-period utilization rises over several reporting periods.
- Investigation checks whether the increase reflects recurring demand or a temporary transfer.
- A recommendation explains the likely constraint and the proposed response.
- A named owner accepts responsibility for approving or arranging the work.
- The change happens within the available planning window.
- Follow-up measurements establish whether the constraint improved.
The vendor does not have to execute every step. Your internal team might own purchasing and configuration changes. The important part is that the handoff is explicit and unresolved recommendations remain visible.
Ask what happens when nobody responds. Does the recommendation disappear into a monthly report, or does it stay open with an escalation path?
An unaccepted recommendation is still an unresolved risk.
2. Make capacity monitoring account for purchasing time
A threshold alert answers a narrow question: has a measurement crossed a configured boundary?
Capacity planning asks a different question: how much time remains to investigate and change the situation?
Consider this hypothetical example:
| Planning input | Example value |
|---|---|
| Current busy-period link utilization | 62% |
| Recent growth | About 4 percentage points per month |
| Locally chosen investigation threshold | 78% |
| Estimated time to that threshold | About 4 months |
| Procurement and implementation lead time | 3 months |
These are illustrative values, not recommended defaults. There is no universal utilization percentage at which every network becomes unhealthy.
Under a simple linear assumption:
Time to planning threshold =
(planning threshold - current utilization) / growth rate
That gives approximately four months. With three months needed to arrange an upgrade, the decision window is already short.
The prediction will be imperfect. Demand can change abruptly, and a short observation period may produce a misleading growth estimate. The point is to connect a measured trend to the time required to respond.
Ask the vendor:
"Do your capacity recommendations account for our actual procurement and maintenance lead times?"
If a service waits until your chosen threshold is crossed before recommending an upgrade, it may detect the problem correctly while still leaving you too little time to fix it.
A useful recommendation includes the observation period, the assumptions behind the estimate, and a date by which someone needs to decide.
3. Check whether the measurements can support the conclusion
A reassuring average can hide a painful busy period. A brief spike can also trigger unnecessary spending if nobody investigates it.
Ask to see how the vendor evaluates one important link or device. The explanation should identify the measurement interval, the period under review, and how normal business activity affects interpretation.
For a link, ask:
- Are inbound and outbound utilization evaluated separately?
- Are interface errors or discards examined when investigating performance?
- Can the collected data distinguish recurring congestion from an isolated event?
- What short events could the collection interval miss?
These are questions about the vendor's proposed coverage, not assumptions that every service includes every measurement.
A graph alone also cannot establish the cause of poor application performance. A busy link might be relevant, but the bottleneck could be elsewhere. Ask what additional evidence the analyst would need before recommending more bandwidth.
Be equally careful with forecasts. A vendor should be able to say that the available history is insufficient for a useful projection. Unsupported precision is not proactive management.
A defensible recommendation might instead call for a longer observation period or a targeted investigation before committing to new equipment.
4. Treat lifecycle planning as a separate responsibility
Performance monitoring does not automatically produce a replacement plan.
A device can appear healthy while approaching the end of its support arrangement. Another device can be old and still meet the organization's requirements. Age alone is a weak replacement argument.
Lifecycle planning needs information that a health check may not contain, such as the exact model, support status, and the business role of the device. It also needs someone to maintain that information.
Ask the vendor:
"Who maintains the inventory and verifies lifecycle dates, and how do those dates become an actionable replacement recommendation?"
Then ask to see a sample planning record. Useful fields include:
| Field | Why it matters |
|---|---|
| Device identity and role | Connects the recommendation to a business dependency |
| Relevant lifecycle date and source | Makes the timing verifiable |
| Observed constraint or replacement reason | Explains why action is warranted |
| Target decision date | Leaves room for purchasing and implementation |
| Responsible owner | Prevents an orphaned recommendation |
| Status and next review date | Keeps deferred work visible |
A replacement recommendation should explain whether it comes from observed performance, support considerations, or another documented concern. Those reasons can justify different priorities.
If lifecycle work is outside the monitoring service, establish who owns it. Otherwise, both parties may assume the other is maintaining the replacement schedule.
5. Test the handoff with a tabletop exercise
Before buying, give the vendor a scenario using invented data. Ask them to walk through their actual process.
For example:
"An important link shows steadily increasing busy-period utilization. Users have not reported a problem. An upgrade takes twelve weeks to arrange. Our IT manager does not respond to the first recommendation. What happens next?"
Follow the scenario through to closure.
Ask when the condition would receive human review. Ask what evidence would appear in the ticket and whether the issue receives a decision deadline. Find out who follows up when the customer does not respond.
Then introduce a complication:
"We cannot fund the upgrade this quarter. How is that decision recorded, and when is the risk reviewed again?"
A useful process can accommodate deferral without pretending the issue is resolved. It should document the decision and preserve visibility of the remaining risk.
Finally, ask:
"After the change, how do you determine whether it helped?"
Closing a ticket because equipment was installed is different from verifying that the original constraint improved.
This exercise also exposes authority boundaries. Monitoring access does not necessarily include permission to change configurations. Establish who may approve work, who performs it, and whether those activities carry separate charges.
6. Look for evidence that the monitoring itself is working
A quiet dashboard can mean healthy infrastructure. It can also mean missing data.
For any collector-based arrangement, ask what happens when the collector stops reporting or loses access to a monitored device. Ask how the service detects stale measurements and how newly installed equipment enters monitoring coverage.
These checks matter because trend analysis depends on adequate history. Gaps can weaken a forecast or hide the period when a problem developed.
Request a clear explanation of how missing data appears in reports. It should not silently become healthy time.
Also ask who reviews alert quality. Repeated non-actionable notifications consume attention. Excessively loose thresholds can hide developing problems. Someone needs to own adjustments and understand what those adjustments might stop detecting.
7. Put the distinction into the service description
Do not let "proactive" carry the entire agreement.
Ask for concrete deliverables and boundaries. These might include a defined trend-review cadence, written recommendations with owners, and follow-up on outstanding capacity decisions. Confirm which are actually included in the quoted service.
A compact comparison sheet can help:
| Buyer question | Evidence to request |
|---|---|
| Who reviews developing conditions? | Defined responsibility and review cadence |
| How early are recommendations raised? | Example tied to implementation lead time |
| What happens after a recommendation? | Ownership and escalation workflow |
| Is lifecycle planning included? | Inventory responsibilities and sample output |
| Who performs corrective work? | Explicit scope and authorization boundaries |
| How is improvement confirmed? | Before-and-after verification example |
There are legitimate tradeoffs. A lower-cost alerting service may be sufficient if your internal team already handles analysis and planning. Broader management requires context and coordination, including effort from your staff.
The buying mistake is paying for one arrangement while assuming you are receiving the other.
Where our own product lands on this
Adaptive IP Services' NOC, Managed Network Operations, provides continuous monitoring of the devices and links a business depends on, covering uptime, performance, and capacity. Collector agents feed a hosted monitoring stack to surface problems early and support scheduled equipment replacement.
That description addresses the monitoring foundation. Buyers should still use the questions above to establish the specific review process, lifecycle responsibilities, and action ownership for their engagement.
The useful test is whether an early signal reaches someone who can make a timely decision, and whether that decision is followed through. Ask to see that process before treating a dashboard as an outage prevention plan.
Disclosure: I work at Adaptive IP Services, a Dallas based IT and security firm.
David J. Boggs
Founder and CEO, Adaptive IP Services
Top comments (0)