UniFi monitoring: options and limits

With UniFi, inping monitors two things: over HTTP(S), whether the interface of the console or controller responds, and with the agent, the Linux server if you run UniFi yourself. inping does not see access points, switches and clients, and the agent does not run on a UniFi OS console.

What are the options?

Which variant you have decides the route. Ubiquiti lists as Cloud Gateways UCG-Ultra, UCG-Max, UDM-Pro, UDM-SE and UDR among others; a Cloud Key is also a console. On your own hardware there is the UniFi OS Server and the Network Server that Ubiquiti lists as "Legacy".

Route 1: check the availability of the interface

In each interval the runner sends one GET or HEAD request and compares the status code with the expected value. It checks nothing more: login, device adoption and wireless networks stay out of scope.

Port 8080 (inform) and the UDP ports for STUN and discovery serve the devices. An HTTP check does not show whether the devices reach their controller. Look up beforehand which status code the address returns, and set it as the expected value; the default is 200.

# Which status code does the console return? -k only for this test: it skips the certificate check
curl -skL -o /dev/null -w '%{http_code}\n' https://192.168.1.1/

Two limitations you should know about

Certificate. The runner always checks certificates, and no exception can be configured. UniFi interfaces usually come with a self-signed certificate from the factory, which counts in the runner as a TLS error and therefore as an outage. It follows redirects from HTTP to HTTPS on the same host, so the result stays the same.

Private addresses. inping's runners cannot reach private addresses. For a console on the LAN you need your own runner there. We do not recommend setting up a public address for the console just to monitor it. The case is different for a controller that runs anyway on a publicly reachable server with a valid certificate, for instance behind a reverse proxy: inping's runners check that with no further setup.

Your own runner on the LAN

The runner runs on Linux with amd64 or arm64, as a service or in a Docker container, for example on a Raspberry Pi. The Free plan includes 1 own runner.

1. Create it as a team admin under Runners → Add runner or in the project under Runners → Add runner. The dialog shows the command with the token. The details are in the installation guide.
2. Allow private networks and restart the runner. In Docker operation, set INPING_PRIVATE_NETWORKS=true in the .env instead. Loopback and link-local addresses always stay blocked.
3. Enter the address as a private IP or with an internal suffix (.lan, .local, .internal, .home.arpa or with no dot). Only such addresses are never assigned to inping's runners. A public name that points to a private IP would be reported by them as an error, and the majority of runners decides the status.

# /etc/inping/runner.toml on the device with the runner
private_networks = true

Checking a console with its factory certificate

Internal addresses and a certificate that inping accepts rarely go together. For a console on the LAN, the target is therefore a small relay on a Linux device that the runner reaches over HTTP and that itself calls the console over HTTPS, for example with Caddy. This is a general reverse proxy route and has not been tested by us on this hardware. The certificate check then does not take place on the stretch to the console, so limit access to this port to your network.

# Caddyfile on a Linux device on the LAN: HTTP on the inside, the console behind it over HTTPS
:8081 {
	reverse_proxy https://192.168.1.1 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

In the project you then enter http://192.168.1.20:8081/, with the status code the console returns there. If the relay fails, it looks in inping like an outage of the console.

What a runner on the LAN does not report

If the internet connection or the runner fails, no results arrive at inping. The status then stays at its last state, and there is currently no alert for a silent runner. The runner keeps results and sends them later. This matters especially with a gateway: if it fails, the runner behind it is cut off too. That is why a view from the outside is part of the picture, see below.

Route 2: agent on your self-hosted server

If you run UniFi on your own hardware, then from inping's point of view it is a normal server, and the agent belongs there. This combination has not been tested by us on this hardware either, but it follows the routes we describe for Linux and Docker.

• UniFi OS Server. According to Ubiquiti it needs Ubuntu 24.04 or newer, Debian 13 or newer or another current distribution with systemd and Podman. Install the agent as on any Linux server. The agent does not report the services in Podman as Services; its Docker route is built for the Docker API and has not been checked with Podman.
• Network Server from the APT package. The same: install as a Linux server. The package unifi appears in the package inventory. For host packages inping matches vulnerabilities against the distribution's advisories, so for UniFi itself rely on Ubiquiti's security advisories.
• Network Application in Docker. We have found no official image from Ubiquiti; a widely used one is from LinuxServer.io, which needs its own MongoDB. You add the agent in the same Compose file as described under Monitor Docker containers. You then see CPU, memory, network, I/O and whether it is running for each service.

curl -fsSL https://www.inping.io/install.sh | INPING_TOKEN=<token> sudo --preserve-env=INPING_TOKEN sh -s --

The app shows the command with a real token under Agents → Add agent. On such a server, the rules for disk and memory and the agent's offline alert are the useful ones.

Why not the agent on the console?

We do not support that, and we advise against it:

• A console is not a general-purpose server. Ubiquiti itself describes updating over SSH as a process that is not officially supported, and we have found no intended route for your own software in Ubiquiti's documentation.
• Firmware updates remove such changes. The community project unifi-on-boot describes how updates rebuild the root file system and installed packages and services disappear. So the agent would regularly be gone without notice, and its own offline alert would be no sign of a real problem.
• The device carries your network. Third-party software on the router and firewall increases the attack surface exactly where it is least wanted.
• There would be little to gain in content either: the agent reads no UniFi data. It would report the console's CPU, memory and disk, no devices and no clients.

What about access points, switches and clients?

inping cannot do that: there are no values per device, no clients, no wireless channels and no port statistics, neither through the UniFi API nor through SNMP or ICMP. An HTTP check is no solution for this either. There are better-suited tools for this level:

• UniFi Alarm Manager: alerts directly from UniFi, for instance for failed devices, by push, email or webhook.
• SNMP in UniFi Network: Ubiquiti names Zabbix, PRTG and Nagios as examples and points out that USW-Flex and Ultra switches do not support SNMP.

Both complement inping: UniFi and SNMP tools know the network, inping the websites and servers behind it.

How do you sensibly monitor a UniFi network?

1. Devices and wireless in the UniFi Alarm Manager, because that is where the data is.
2. View from the outside. If you have a publicly reachable service behind the gateway, inping's runners check it from other locations. If it stops responding, the cause lies with the service, the gateway or the internet connection.
3. View from the inside. A Linux server on the LAN with an agent: its offline alert comes from the platform, even when nothing on the network is sending any more. But it only says that reports have stopped arriving, not why.
4. Internal services. With your own runner on the LAN you check what is only reachable internally, and see response times from your network's point of view.

What does it cost?

The Free plan is enough to get started: 2 agents, 1 own runner and 10 URLs per project, checked as often as every 60 seconds. The other plans are listed under Pricing, the installation routes under Integration.

Frequently asked questions