Your site answers from outside: how do you know nothing inside is stuck?
In short
A public site says nothing about the server, the storage, the gateway or the machine that actually runs the business, because none of them are reachable from outside. Watching them means asking from inside the network — and the honest boundary is that a device answering is not the same as a device doing its job.
Ask most people whether their systems are up and they will tell you about the website. It is the part with a public address, the part that can be checked from anywhere, and it is a small fraction of what the business actually runs on.
The file server has no public address. Neither does the storage, the virtualisation host, the printer that produces the delivery notes, the gateway in the technical room, or the machine in the workshop that has run the same job since 2019. Nothing on the internet can see any of them. That is a deliberate and correct security decision, and it has one consequence: you cannot check them from outside, so most people do not check them at all.
What does “inside the network” mean in practice?
It means something small that lives on the same network and asks questions on your behalf: a lightweight appliance on a spare machine, a virtual machine, or just an agent on a Linux box you already have.
The direction of travel is what makes it acceptable. It opens an outgoing HTTPS connection, the same way a browser does, and nothing is opened inwards: no port forwarding, no VPN, no fixed public address. Networks where “can you open a port” ends the conversation are exactly the networks where this has to work.
Once it is there, it can ask for reachability of anything with an address, and — where you give it credentials — for real numbers: processor, memory, disk and load on Linux and Windows machines, SNMP values from storage, switches, printers and UPS units, the state of virtualisation hosts and of server management controllers. If you want, it can look around the network ranges you declare and propose what it finds, so you are not typing addresses from a spreadsheet.
Which failure is this really about?
Reachability is the easy half; the expensive one is the device that answers perfectly while doing nothing.
A gateway in front of a building automation system will happily answer on its network address with the bus behind it dead. A data point left in a forced or out-of-service state reports a plausible value forever. An import that stopped three weeks ago leaves a service that still responds to every request instantly, because it has nothing to do. In all three the dot is green and the work is not happening.
There is an honest way to catch these, and a dishonest one. The dishonest one is to claim that a monitoring system can tell, from outside, that a device is doing its job. It cannot. The honest one is to make the work itself produce a number: how old the last processed file is, how many items are waiting, how many minutes since a value last changed. You already have a command that can print that, or you can write one in five lines. A metrics monitor can run up to eight of your own commands and turn each printed number into a monitored value with a warning threshold and an alarm threshold.
That is the whole trick, and it is worth saying plainly: we do not detect that your system stopped working. We watch a number your system produces, and that number stops moving.
What to do this week
- Write the list of what the business would stop without, and mark which of those have a public address. The unmarked ones are the gap.
- Put a probe inside the network and start with reachability of everything on that list. It takes an afternoon and it already changes the conversation.
- Add credentials where you have them, so the important machines report numbers instead of a dot.
- Pick the one process whose silent failure would hurt most and make it print a number — file age, queue depth, minutes since the last change. Watch that number.
- Make sure the probe itself is watched, so that silence from inside means something.
Outside monitoring tells you what your customers can see. Inside monitoring tells you whether the business is still working. They are not the same question, and only one of them is usually being asked.
What we cannot tell you
- We cannot see a device that publishes nothing: if it has no way to be asked, all we can tell you is whether it answers on the network at all.
- We cannot read an automation or building bus — KNX, BACnet and the like: today we see the gateway that sits in front of it, not the bus behind it.
- We cannot tell you on our own that a value has frozen. If your own command prints how long it has been since something last changed, we watch that number and alert on it — the calculation has to come from your side.
- We cannot discover what you have not declared: the probe looks only in the network ranges you give it, and only if you switch discovery on.
Questions people actually ask
Why can a service outside be fine while something inside is dead?
Because they are different machines doing different jobs. The public site is the small part of the business that faces the internet. The file server, the storage, the virtualisation host, the machine that prints the delivery notes — none of them are exposed, on purpose, so nothing on the internet can tell you anything about them. Their silence is not evidence of health, only of being unreachable.
Do I have to open ports or set up a VPN for this?
No, and you should not have to. A small probe inside the network makes an outgoing HTTPS connection and nothing else: no inbound ports, no VPN, no fixed address. It is the same direction of traffic as a browser, which is why it works in networks where opening anything is out of the question.
What can it actually ask a server or an appliance?
Reachability for anything with an address; and with credentials, real numbers: CPU, memory, disk and load on Linux over SSH, the equivalent on Windows, SNMP values from storage, printers, switches and UPS units, and the state of virtualisation hosts and server management controllers. Each of those is a number with a threshold, a chart and a history, not a red or green dot.
How do I catch the thing that answers but has stopped working?
By watching a number that only moves when the work is happening: the age of the last processed file, the depth of a queue, how long since a value last changed. On a metrics monitor you can run up to eight of your own commands, and whatever number each one prints becomes a monitored value with warning and alarm thresholds. That is how a job that quietly stopped becomes visible.
How many monitors does a server need?
In practice two to four: one that covers CPU, memory and disk together, plus one for each service on it that matters. As a rough guide, fifty monitors covers something like fifteen to twenty-five servers — useful when you are working out which plan fits before you install anything.
What happens if the probe loses its connection?
It keeps checking and stores the results locally, then replays them when the link comes back, so the history has no hole and the outage is not blamed on your services. And a probe that stops reporting is itself an alert — silence has to mean something, or it means nothing.