We find out first.
Our monitoring platform talks to your MikroTik devices over the RouterOS API once a minute. It knows when a link drops, when a router is running hot, when something rebooted at 3am and when firmware has drifted out of line across your estate.
11:32:04 poll 42 devices in 417ms 11:32:04 ok 41 up 11:32:04 alert kloof-backup device_down 11:32:05 notify engineer via SMS + email 11:32:11 ack acknowledged by on-call 11:47:52 clear kloof-backup restored outage 15m 48s · client not affected
What we watch
Every device, every minute.
Availability
Reachability per device, with rolling 24-hour and 30-day figures. This is what a service level is measured against, so we measure it continuously rather than estimating it afterwards.
Device health
CPU load, memory, storage, temperature, supply voltage and uptime. A router that has started running hot is a router that is about to fail.
Interfaces and throughput
Per-interface state, error and drop counters and derived throughput. A link that has started dropping frames shows up long before users complain.
Service load
PPPoE sessions, hotspot users, DHCP leases and wireless registrations. Useful for capacity planning and immediately obvious when it falls off a cliff.
Firmware drift
RouterOS and RouterBOOT versions across your whole estate, with pending upgrades flagged. This is how an old exploitable version stops hiding in a cupboard.
Unexpected reboots
A device with a suspiciously short uptime tells you something — a power problem, a failing supply, or a change nobody logged.
How it is built
Our own platform, not a reseller's dashboard.
We wrote it, we run it, and we extend it when a client needs something it does not yet do. It speaks the RouterOS REST API on v7 and the legacy binary API on v6, so it covers the devices you actually have rather than only the new ones.
It is hosted on our infrastructure and reaches your equipment over a tunnel using a read-only account restricted to our address. It can see your network. It cannot change it.
Alerting that reaches a person
- Thresholds tuned per device, not one global rule
- Repeat notifications rate-limited so a flapping link cannot cause alert fatigue
- Alerts clear themselves when the condition resolves
- Every alert carries the device, the client, the site and the measured value
Monitoring that nobody reads is theatre. Ours is wired to whoever is on call.
Questions
About the monitoring.
What access does monitoring need?
A read-only RouterOS user, restricted to our monitoring host's IP address, reached over a tunnel. It can read status. It cannot change your configuration.
Will it slow our routers down?
No. A poll is a handful of read commands once a minute and costs a fraction of a percent of CPU on even the smallest hAP.
Does it work on older RouterOS?
Yes. We support RouterOS v7 over the REST API and RouterOS v6 over the legacy binary API, so devices that have not been upgraded yet are still covered.
Do we get access to it ourselves?
A per-client view is on our roadmap and included when it ships. Today you receive alerts as they happen and a consolidated report each month.
See it running before you commit.
We will walk you through the live view on a call, then connect one of your own devices so you can watch it appear.