Why You Shouldn't Build Your Monitoring on External Scripts

Every monitoring platform has gaps. Some devices are not covered, some counters are not exposed, and some APIs are new. There are two ways to close such a gap: build the capability into the product, or let the customer script around it.

The second option is cheaper in the short term, which is why it is so common. PRTG, for example, relies on it heavily. Its Sensor Hub is a marketplace where scripts written by Paessler and by PRTG users are offered to everyone as monitoring "sensors". The site says it plainly: "Who could write better scripts than you? ... We want your scripts!"

And just as plainly, in small print: "These scripts are not part of PRTG and Paessler does not support them."*

We think that small print is the whole story in one sentence. Building your monitoring on external scripts means building it on unsupported code — and the costs show up in three places: performance, security, and maintenance.

Scripts Are the Slowest Way to Measure Anything

A native sensor is code that lives inside the monitoring engine. It is loaded once, compiled, and at every polling interval it does the smallest possible amount of work: read a counter, parse a packet, run a query.

A script sensor is the opposite. Every single poll starts an external process from scratch:

• the operating system creates a process,
• the interpreter starts (PowerShell alone takes seconds to warm up),
• the runtime is loaded, the script file is read and parsed,
• the script does its work, prints its result,
• the process is torn down and its memory reclaimed.

That is not monitoring — that is process spawning with a measurement attached. A script sensor that polls once a minute spawns 1,440 processes a day. Ten such sensors: almost 15,000 process starts every day, each one paying the full interpreter startup cost. Multiply that by hundreds of devices and the monitoring server spends a large part of its CPU just starting and stopping interpreters.

This is why script polling is structurally the slowest monitoring model. It does not get better with a faster machine — a faster machine just lets you spawn more interpreters. And every cleanup failure (a hung script, a process that was not closed, an unread pipe) accumulates until the monitoring machine itself becomes the thing that needs monitoring.

The toll does not stop at process startup. Every script that reaches into a remote system pays for its own connection: three scripts polling the same machine each open their own SSH session — handshake, authentication, channel setup — and each tears it down when it is done. That is three connections, three round trips of setup, and three cleanups for what one native sensor does with a single connection held open and reused for every poll. On a large estate the wasted time compounds exactly the same way wasted CPU does.

Scripts Are a Security Problem You Cannot Audit

The people who write most monitoring scripts are not programmers. They are network administrators and system engineers who needed a result and knew just enough scripting to produce one. The result usually works — and is never reviewed from a security perspective.

Consider what such a script carries:

• it runs with the monitoring system's credentials, which are often elevated,
• it parses text, calls APIs, and connects to remote systems,
• it may contain secrets — passwords, tokens, API keys — hardcoded or in plain text files,
• it runs on a schedule, unattended, for years.

A bug in such a script is not a feature gap; it is an exposure. And with community scripts, the problem is worse: you do not know who wrote it, whether it was reviewed, or whether it still works the way it did when it was uploaded. The Sensor Hub hosts hundreds of third-party scripts, explicitly unsupported and unvetted. Putting one of those on your monitoring server is roughly equivalent to downloading a random administrator's PowerShell from the internet and running it with your credentials.

That is a risk no feature is worth.

A Script Is a Point Solution — Not a Product

The most important question about script-based monitoring is what happens after the script works.

A script returns a number. Everything that makes that number useful in a real monitoring platform — history, thresholds, trending, dependencies, alert correlation, dashboards, reports — you have to build yourself, because the script is outside the platform. The script sensor gives you a value on a screen; the platform cannot know what it means.

Then the maintenance starts. Operating systems change, APIs change, device firmware changes the format of its output. Every change is a debugging session in someone else's code. And when the script stops working, support will tell you — as Paessler does, in advance — that the script is not part of the product.

PRTG's own script sensors show how alerting logic quietly ends up in the wrong place. Their output format lets a script declare the same four limits a native channel has — upper and lower error, upper and lower warning. The values are read once, when the sensor is first created, and become the channel's limit settings; after that they live in PRTG and can be changed in the channel settings. In practice this means every script-based monitor is born with alerting thresholds taken from unsupported user code: unvetted numbers, identical for every device the script is applied to, until somebody notices and edits each channel by hand. The alerting logic was never designed in the platform — it was copied into the monitoring from the script.

Scripts are the right tool for a genuinely niche case that affects one customer, once. That is what they are for. They are the wrong tool for covering the gaps that every customer of the platform hits — because those gaps should not be gaps at all. They should be product features.

What We Do Instead: Ship the Sensor

At NetCrunch, we prefer to do the work ourselves.

When customers need something monitored that we do not cover, we treat it as a feature request, not as homework for the customer. The request goes through the normal product process: it is evaluated, built as a proper sensor, tested, documented, and shipped with a NetCrunch release — covered by support, updated when things change, and integrated with thresholds, alerts, history, and dashboards from day one.

That is why NetCrunch ships hundreds of monitoring packs and sensors, and why the gap-closing happens in our release notes rather than in a community script repository. Yes, NetCrunch has script sensors too — for the genuinely narrow case, where a native sensor would be overkill and the customer has a reason to own the code. That is the point-solution use of scripts, and it is the right one. What we do not do is promote user scripts as a substitute for the product.

In NetCrunch, the boundary is drawn the other way: the sensor — native or script — is only a data source. All monitoring logic lives in NetCrunch itself. Thresholds, in every flavor the platform offers — upper and lower, warning and error, per counter, and more — are configured and changed at any time in the UI, and they apply to the channel, not to the code. Change a threshold at 3 a.m. and it takes effect immediately; nothing is edited, redeployed, or re-created. That is what separates the NetCrunch model from older systems such as Nagios, where thresholds travel as command-line arguments to plugin scripts — -w 80% -c 90% and the like — and live in configuration files that are edited by hand and reloaded. There, the monitoring logic is spread across scripts and config files; in NetCrunch it is centralized, visible, and under the administrator's control.

The difference in approach is easy to see. One vendor's hub page asks users to write the monitoring for it. Ours ships the monitoring and asks users to tell us what is missing — and then builds it.

An Honest Word About the Sensor Hub

We want to be fair to Paessler. A monitoring product cannot cover every vendor, every API, every niche, and a script marketplace is a pragmatic answer to a real problem. The Sensor Hub is also remarkably honest: it labels its scripts as unsupported, and it invites users to contribute with full transparency about what the contribution is.

Our disagreement is with the direction, not the honesty. A monitoring vendor that makes its users its sensor development department is telling them that the product's boundaries are their problem to solve. That is a statement about the product — and the support burden it places on the customer is exactly the work a monitoring platform exists to remove.

Before you build monitoring from scripts, ask three questions:

1. Who maintains this in two years?
2. Who reviewed it for security?
3. What does it cost — in CPU, in risk, in your team's time — across a hundred devices, polling every minute?

If the answer to any of them is "the customer", it is not monitoring. It is work in disguise.

Summary

PRTG and Paessler are trademarks of Paessler GmbH. All other trademarks, logos, product images and copyrights are the property of their respective owners.

monitoringnetcrunchpaesslerperformanceprtgscriptsecuritysensor