Monitoring tools have never been more powerful or easier to misuse.
With monitoring solutions, it’s possible to collect an overwhelming amount of data across every device, sensor, and metric imaginable. That capability is valuable, but it also creates new failure modes: noise, fatigue, and wasted effort.
As we head into another year of managing increasingly diverse and distributed environments, it’s worth taking a step back and asking a simple question:
Is your monitoring actually helping you prevent problems, or just creating more work?
I’ve talked with a lot of folks who do and do not deploy monitoring solutions this year and wanted to share what I believe to be the naughty and nice list for network monitoring.
The Network Monitoring Naughty List
- Monitoring everything because you can
This is one of the most common traps. Tools like Domotz make it easy to collect large volumes of data, and features like custom scripting open the door to even more. The temptation is obvious: if a metric exists, why not monitor it?
Because more monitoring does not automatically lead to better outcomes.
- EMA estimates that up to 80% of IT alerts provide little to no operational value, forcing teams to spend more time sorting noise than fixing real issues.
- More than 75% of managed service providers experience alert fatigue at least once a month.
The problem isn’t visibility, but it can be lack of intent.
Effective monitoring starts with focus. The goal is not to measure everything, but to monitor the metrics and behaviors that directly correlate with uptime, performance, and user impact. If a signal doesn’t inform a decision or trigger an action, it’s probably not worth monitoring.
Which leads to the next mistake.
- Alert logic that ignores business impact
Every alert should exist for a reason. If an alert fires, someone should know exactly what to do next.
Before enabling an alert, ask three simple questions to determine the impact to the business:
Too often, alerts are configured around thresholds without considering whether a breach actually requires action. A warning that doesn’t change behavior isn’t helpful, it’s a distraction.
- Where is the issue?
- What does it affect?
- Who does it impact?
If you can’t answer those clearly, the alert might not be worth it.
- Ignorance is bliss.
If no one is complaining that doesn’t mean everything is fine. Most outages and performance degradations are invisible until damage is already done.
When users are the first line of detection, IT immediately ends up on the defensive. By the time a ticket is submitted, productivity may already be down, revenue may be impacted, and trust may be eroding.
Knowing what’s happening across your environment allows you to act earlier, fix issues faster, and avoid being surprised by problems you “didn’t know existed.”
- Only deploying monitoring to a subset of sites
This one can be controversial.
Many teams monitor only their largest locations, newest deployments, or most “important” sites, leaving everything else unmonitored. Edge locations, smaller sites, and legacy environments are often excluded.
Yet Verizon’s DBIR consistently shows that edge locations are among the most common sources of outages.
The reason is usually cost.
This is where Domotz pricing matters. You can deploy Domotz Collectors to unlimited sites at no cost. You’re only charged per device when you choose to actively monitor or manage it. That means you can deploy everywhere and enable monitoring instantly when needed, rather than scrambling to install tooling during an incident.
Coverage matters, even if not every device is actively monitored on day one.
- Relying entirely on default settings
Defaults are designed to work generally, not optimally.
Out-of-the-box thresholds, polling intervals, and alert rules don’t know what “normal” looks like in your environment. Yet many teams assume the tool will magically figure that out.
- EMA research shows that organizations that customize monitoring and alerting reduce mean time to resolution by up to 30% compared to those relying solely on defaults.
Defaults can be a starting point. They shouldn’t be the finish line.
The Network Monitoring Nice List
- Standardizing monitoring with device profiles
One of the biggest causes of monitoring inconsistency isn’t tooling, it’s how the devices are configured.
When devices are configured one by one, outcomes depend on who set them up, when they did it, and what they thought mattered at the time.
- EMA research shows that nearly half of monitoring failures are tied to misconfiguration or inconsistent policies.
For Domotz users, Device Profiles address this directly. Profiles allow you to standardize monitoring and apply it consistently at scale:
- Create, edit, clone, and assign reusable device configurations
- Apply only the modules you need (properties, SNMP credentials, alerts, sensors, TCP checks)
- Bulk-apply profiles using static or dynamic filters
- Automate profile assignment via API
The result is predictable monitoring behavior and fewer surprises.
- Expanding monitoring access beyond specialists
Deep monitoring expertise is often concentrated in a small group of senior engineers. While some controls should remain restricted, visibility shouldn’t be.
- IDC estimates a global shortage of more than 4 million skilled technology professionals.
When all complexity flows through a few people, they become bottlenecks, and burnout follows. Giving lower-tier technicians access to visibility, context, and historical data allows more issues to be identified and resolved earlier.
This doesn’t replace expertise, but it does give senior engineers more time to focus on architecture, optimization, and long-term improvements instead of constant firefighting.
- Thinking in terms of issues, not devices
Monitoring often defaults to device-level thinking. Devices are priced individually, alerts fire individually, and problems are described individually.
But incidents rarely respect those boundaries.
Shifting to an issue-level mindset helps teams reduce noise, identify root causes faster, and respond more effectively. Devices still matter, but issues are what actually need to be resolved.
- Proactive reporting, not just proactive monitoring
Monitoring is proactive by definition. Reporting is where the value becomes visible.
Imagine catching a failing UPS battery before it takes down everything connected to it. You fix the issue before anyone notices. Technically, nothing “broke.”
But the work still mattered.
Proactively reporting what you’ve identified and prevented demonstrates value, builds trust, and changes how stakeholders perceive your role. Some organizations even notify stakeholders with an alert when issues are detected early, before they escalate.
That may not be right for everyone, but the principle holds: work that isn’t communicated often goes unrecognized.
- Deploying monitoring before onboarding new environments
For service providers especially, one of the most overlooked moments to deploy monitoring is before onboarding a new client or environment.
Closing a contract only to discover unknown devices, or worse devices you aren’t charging for, after the fact creates friction immediately. Manual discovery is time-consuming and error-prone.
With Domotz, you can deploy a Collector purely for discovery and real-time device status at no cost. You’re only charged when you choose to actively monitor or manage devices.
That early visibility sets expectations, reduces surprises, and protects margins from day one.
Final Thought
Good monitoring isn’t about collecting more data. It’s about collecting the right data, acting on it intentionally, and making sure the effort translates into real outcomes.
If your monitoring strategy reduces surprises, shortens response times, and earns trust before problems escalate, you’re on the nice list.
Everything else is just noise. Ready to take your monitoring to another level?
