Your UniFi console is excellent while you’re looking at it. Close the tab and it goes quiet. The switch that dropped a port at 3 AM, the AP that rebooted twice overnight, the WAN link that dipped for ninety seconds — you find out when someone complains. Here’s how to put real alerting on that hardware in about five minutes, without exposing anything to the internet.
Network gear knows its own state perfectly. It counts every byte on every port, tracks whether each link is up, and remembers exactly how long it’s been running. It just has no way to tell you when something changes — it waits for you to come and look.
That’s fine for a lab. It’s not fine when the gear is carrying a house full of cameras, a home lab, or a small office. What you actually want is:
SNMP is the answer — every serious piece of network hardware speaks it, and has for decades. The problem is how it’s normally used: something outside your network reaches in to poll port 161.
That’s the part to avoid. SNMP runs over UDP, and in the v1/v2c form your gear supports, the “password” is a community string sent in the clear. Exposing that port to the internet means publishing a cleartext-authenticated UDP service on your edge device. Nobody should do that, and you shouldn’t have to.
The alternative is to run a full network-management stack inside your network — a server, a database, a web front end, and its own upkeep. That’s a lot of machinery to answer “did the WAN drop last night?”
There’s a smaller shape that gets you everything. Run a tiny agent on any machine already sitting on that network — a Pi, a NAS, a spare mini PC, the box you already run things on. It polls the UniFi device over SNMP locally, then pushes the readings out over an ordinary outbound HTTPS connection.
SNMP never leaves your LAN. Nothing listens for inbound connections. It works behind NAT, CGNAT, and any firewall that lets a machine make outbound requests — which is all of them.
pylon-beacon is that agent: one static binary, no dependencies, no runtime to install. It already reports the host’s own vitals; the [snmp] section adds anything on the network that answers SNMP.
In the UniFi Network application, open Settings → System → Advanced and enable SNMP. Choose v2c and set a community string — that’s the read password. Use something other than the default.
Note the device’s LAN address while you’re there. That’s what the agent will poll.
On any Linux box on the same network:
curl -fsSL https://pylonmon.com/beacon.sh | sh
Windows, in an admin PowerShell:
irm https://pylonmon.com/beacon.ps1 | iex
The installer asks for an API key. Create an ingest-scoped key in the portal under Settings → Status page & API. An ingest key can push readings and do nothing else — it can’t read your monitors or change your account.
Open the config — /etc/pylon-beacon.conf on Linux, beacon.conf next to the executable on Windows — and add an [snmp] section:
[snmp] target = 192.168.1.1 community = your-community-string timeout = 3 # Every other line is: metric name = the OID to read uptime_ticks = .1.3.6.1.2.1.1.3.0 wan_in_octets = .1.3.6.1.2.1.2.2.1.10.1 wan_out_octets = .1.3.6.1.2.1.2.2.1.16.1 wan_oper = .1.3.6.1.2.1.2.2.1.8.1
These are standard MIB-II identifiers — the same four numbers work on switches, routers, firewalls, NAS boxes and printers, not just UniFi.
What each one gives you:
sysUpTime — hundredths of a second since boot. When this drops, the device restarted.ifInOctets / ifOutOctets — bytes in and out on one interface. A counter that keeps climbing; the shape over time is your throughput.ifOperStatus — 1 when the link is up. Anything else means it isn’t.The trailing number on the interface OIDs is the port index. Index 1 is the first interface; increase it for the others until you find the one you care about. Add as many lines as you like — one per port, or one per device by running several agents.
The four OIDs above are the standard set, and they cover what you actually page on: link up or down, throughput, and reboots. Ubiquiti also publishes its own tree, and everything UniFi-specific lives under the enterprise arc .1.3.6.1.4.1.41112.
What sits under there varies by model and firmware, so read it off the device itself rather than copying a list. From any Linux box on the network:
snmpwalk -v2c -c your-community-string 192.168.1.1 .1.3.6.1.4.1.41112
Every line that comes back is an OID you can drop straight into the config, exactly like the standard ones.
Anything that answers with a number becomes a metric. Names, locations and other text are ignored, so you can walk the tree freely and add whatever looks useful — per-radio client counts, PoE draw, per-SSID counters — without worrying about picking the wrong thing.
Restart the agent and the readings appear on that node’s monitor within a minute. Now set the rule that does the actual work.
Every SNMP poll also reports snmp_up, which is 1 when the device answered and 0 when it didn’t. That distinction matters more than it looks. A metric that simply stops arriving can’t page you — there’s nothing to compare against a threshold. A metric that reports 0 can. So snmp_up turns a silent device into an alert:
Two minutes of sustain means a single missed poll during a firmware update never wakes you — but a device that’s genuinely gone does.
Add a second rule for the link itself:
From here the rest of the platform applies unchanged: the alert routes through whichever channels you use, escalates if nobody acknowledges it, opens an incident you can annotate, and sends a recovery notice when the link comes back.
The whole configuration is four lines and a section header. The agent is one binary you can delete by removing a file. And because the polling happens inside your network while only the results travel out, the security posture of your edge device is exactly what it was before you started.
Monitor your network gear — free → or read the pylon-beacon overview and the server monitoring guide.