Unified Network Monitor
Every client network on one screen, with the ticket already open when a site goes down.
- 5 min
Every site checked
- 3 vendors
One console
- Daily
Advisories matched to devices
- 180+
Automated tests
Built for E3 IT Services' engineers, watching the networks we manage for clients
What it was like before
Managing networks for many clients means many vendor consoles. Each one knows about its own devices and nothing else, and none of them knows which client a site belongs to or what should happen when something breaks.
So the first sign of trouble was too often the client calling: the internet is down, the Wi-Fi is gone, nothing can reach anything. By then the outage had a head start, and an engineer still had to find the right console, the right site, and the right ticket before the real work began.
Security advisories had the same gap. When a vendor published a vulnerability, working out which client devices it actually affected meant matching models and firmware versions by hand.
How it works
The short version, before the exploded view goes component by component.
We built one console over all of it. Every five minutes it polls the UniFi Site Manager cloud API for every site we manage, reads SonicWall and Cisco Meraki through their own read-only APIs where those are in place, and records every finding against the client it belongs to.
It looks for the failures that actually stop a business: a site down, a device offline, a WAN link down, a failover to the backup internet line, latency above 250 milliseconds, and firmware updates waiting to be applied. On firewalls it also watches VPN tunnels and licenses about to expire.
Once a day it reads Ubiquiti's security advisories and matches each one to the devices it affects by model and firmware version, scored with the CVE severity from the National Vulnerability Database and FIRST's EPSS estimate of how likely it is to be exploited. A vulnerability goes from a news item to a list of the exact devices that need attention, most urgent first.
Tickets follow from findings. Each issue gets one ticket, on the right client's company in Autotask. Critical issues open one automatically; warnings wait on the dashboard for an engineer to judge. When the device or link recovers, the ticket is resolved with a note saying so, and ticket status is read back from Autotask so the two systems never disagree.
Restraint was designed in. A dry run of the first version showed it would have opened seventeen tickets at once, many for routine notices like available firmware updates, so only critical issues open a ticket on their own. The monitor watches itself too: a vendor API that starts failing, or a site that cannot be matched to a client, raises its own issue, so a gap in coverage is never silent.
Engineers work from a dashboard that refreshes every two minutes: summary cards, critical, warning, and system tiers, a WAN and internet panel, open tickets, a vulnerability view, and a table per vendor. From any issue they can open or link a ticket, dismiss it with a reason, log time, or mark it handled. Credentials sit in Key Vault behind a managed identity, and who can do what follows Entra ID roles.
One outage, start to finish
A genuine sequence, which is why these are numbered: from the moment a site drops to the moment its ticket closes.
- 01
Poll
Every five minutes the monitor asks each vendor's cloud API for the state of every site, device, and internet link.
- 02
Detect
A site down, a device offline, a WAN link lost, a failover to backup internet, or latency over 250 ms is recorded as an issue against the client it belongs to.
- 03
Triage
Each issue is graded. Critical issues go straight to ticketing; warnings wait on the dashboard for an engineer's judgement.
- 04
Ticket opened
One ticket per issue, opened on the client's company in Autotask with the detail an engineer needs to start work.
- 05
Engineer acts
The issue is on the dashboard within two minutes. Engineers link it to an existing ticket, log time, dismiss it with a reason, or mark it handled.
- 06
Recovery
When the device or link comes back, the issue clears and its ticket is resolved with a note saying so.
- 07
Reconciled
Ticket status is read back from Autotask, so the console and the ticketing system always agree on what is still open.
Every moving part
The monitor pulled apart plane by plane, from the vendor APIs it reads to the console engineers work in.
Exploded view
Six planes, 18 components. Select a layer to open it.
UniFi sites
UniFi Site Manager API
Sites, devices, WAN links, latency, failover, and pending firmware across every UniFi site we manage.
SonicWall firewalls
MySonicWall + NSM APIs
Read-only firewall health: device status, WAN, VPN tunnels, and license expiry.
Cisco Meraki networks
Meraki Dashboard API
Read-only device, uplink, and license status, handled the same way as the other two.
This console watches the networks E3 IT Services manages for its clients, every five minutes of every day, and managed IT clients get its attention without asking for it. If you run your own network team or a multi-site business, we can build the same kind of console over the equipment and ticketing system you already use. It is a project engagement, scoped and quoted like any other build.
Other things we built
Tell us what you are stuck with.
We will tell you whether it is a build problem, a configuration problem, or something you should not spend money on at all.