UnPoller: exporting UniFi controller metrics to InfluxDB, Prometheus and Loki

The gap UnPoller fills between a UniFi controller and your metrics stack

A UniFi controller keeps statistics for the sites, devices and clients it manages, and it exposes them through its own API. What it does not do is hand those numbers to a general purpose time series database in a format your existing dashboards understand. UnPoller sits in that gap. The README describes it as a small Golang application that collects controller data and reports it to an InfluxDB instance, or exports it for Prometheus collection.

The audience is narrow and specific. You need a UniFi controller already running, which the README treats as a precondition rather than a feature: it states plainly that the application requires the controller to be running all the time. If your controller is a CloudKey, a Dream Machine, or software on Windows, macOS, FreeBSD, Linux or Docker, the README lists all of those as places the controller can live. UnPoller itself runs on the same spread of platforms plus Docker, and the README notes it works on Windows too.

The payoff is dashboards rather than raw metrics. The README points to thirteen Grafana dashboards, six built for InfluxDB and seven for Prometheus, with screenshots on the documentation site. That split matters: the two backends produce different query languages, and the dashboards are not interchangeable between them.

Polling versus scraping: the two modes inside UnPoller

UnPoller has two distinct operating shapes and the README is explicit about both. In Influx mode it polls a UniFi controller every 30 seconds for measurements and exports the data to an Influx database. That is a push model with a fixed interval, and the interval is a property of the poller rather than of your storage layer.

In Prometheus mode the behaviour inverts. The poller opens a web port and accepts Prometheus polling, converting UniFi controller API data into Prometheus exports on the fly. Nothing is stored by UnPoller in this mode; it answers a scrape and forgets. That means retention, downsampling and alerting all belong to Prometheus, exactly as they would for any other exporter.

A third path exists for event data. Since Poller v2.0.2, the README states, Loki is supported along with collection of UniFi events, alarms, anomalies and IDS data. That data can be exported to Loki or InfluxDB, or both. The wording matters: metrics and events are not the same stream, and the README treats the Loki path as the home for the event-shaped records. If you only stand up InfluxDB, you are not collecting the IDS and anomaly material.

The dependency list in go.mod is consistent with this design. It imports github.com/unpoller/unifi/v6 for controller communication, github.com/influxdata/influxdb1-client and github.com/InfluxCommunity/influxdb3-go/v2 for the Influx side, github.com/prometheus/client_golang for the export side, and github.com/DataDog/datadog-go/v5 for a DogStatsD path. OpenTelemetry metric exporters for OTLP over gRPC and HTTP are also present, which tells you the output surface is wider than the README's two headline modes.

Installing UnPoller and pointing it at a controller

The README does not carry install steps. It says to see the documentation at unpoller.com, and points at the issue tracker and the GoLift Discord server for help. The repository does show how the project is packaged: a Makefile driven by settings.sh, a .goreleaser.yaml, a Dockerfile, and example configuration files under examples/ named up.conf.example, up.json.example and up.yaml.example.

The Dockerfile is worth reading before you deploy. It copies examples/up.conf.example into /etc/unpoller/up.conf in the image, described in the file as the example config for cnfg environment-based default config, then runs the binary from a distroless static base. The healthcheck runs the binary with a --health flag every 30 seconds.

FROM busybox:latest AS builder
RUN mkdir -p /etc/unpoller
COPY examples/up.conf.example /etc/unpoller/up.conf

FROM gcr.io/distroless/static-debian13
COPY ${TARGETPLATFORM}/unpoller /usr/bin/unpoller
COPY --from=builder /etc/unpoller /etc/unpoller
HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=3 \
  CMD ["/usr/bin/unpoller", "--health"]
ENTRYPOINT [ "/usr/bin/unpoller" ]

Because the base image is distroless, there is no shell inside the container. Configuration has to arrive through the config file path, through environment variables, or through a mounted file. The examples directory also contains Kubernetes manifests, examples/k8s_influx.yaml and examples/k8s_unifi_poller.yaml, which are the closest thing in the repository to a deployment recipe.

# From the repository root, the Makefile builds the binary.
make
# Local builds take the version from the current git tag.

The Makefile notes that CI passes the version in and that local builds get it from the current git tag, so a build outside CI carries whatever tag you are standing on. What you should see after a successful build is the unpoller binary in the repository root, alongside generated man page and HTML artifacts if you ran the man target.

Where UnPoller stops being the right tool

The most concrete limitation is the one the README states itself: the controller must be running all the time. UnPoller is not an agent on the devices and it does not buffer. If the controller goes down, the poller has nothing to read, and in Influx mode the 30 second poll simply produces no points for that window. There is no documented replay or backfill, and the README does not describe a queue.

The second constraint is version compatibility. The README badge lists UniFi 5.12.x and 5.13.x alongside UAP, USG, USW and UDM as supported products. Controller software moves faster than that list suggests, and the README does not describe how UnPoller behaves against an untested controller release. A controller API change can break collection without the poller failing loudly, since a poll that returns unexpected shapes is not the same as a crash.

Third, this is a metrics shipper, not a monitoring system. It has no alerting of its own, no retention, and no query interface. If you want to know that an access point dropped off the network at 3am, UnPoller supplies the data point and something else has to notice it. The alerts/ directory exists in the repository, but the README does not document what runs from it.

Finally, the README's own framing is opinionated in a way worth reading literally. It says that if you run a UniFi controller there is no excuse not to install Influx or Prometheus, Grafana and this app. That is a project with a strong view of the stack it belongs in. If you are running a different metrics backend, UnPoller is not built around your case.

UnPoller against SNMP polling and the controller's own graphs

The obvious alternative is SNMP. The UniFi controller has long been polled with SNMP exporters, and the community forum post linked from the README is titled around storing UniFi controller metrics in InfluxDB without SNMP, which frames the comparison directly. The difference in approach is where the data comes from. An SNMP exporter asks each device for its MIB values over the network, so you need SNMP reachable on every switch, gateway and access point, and what you get is whatever the MIB exposes.

UnPoller instead reads the controller's API. One connection to the controller yields site, device and client data for the whole deployment, and the fields come from what the controller already knows rather than from a device-level MIB. That is why the README can claim collection of client data and IDS events, which are controller concepts rather than per-device SNMP objects. The trade-off is coupling: your monitoring depends on the controller being up, and on the controller API staying compatible.

The other alternative is doing nothing and reading the controller's built-in graphs. Those exist, they require no deployment, and for a small site they may be enough. They also give you no retention control, no cross-site queries, and no way to join network metrics with anything else you monitor. UnPoller's value appears when UniFi data needs to sit next to other time series in the same Grafana instance.

Maintenance, packaging and the MIT licence

The repository is not archived, and the last push was on 2026-09-24. Releases v5.2.8, v5.2.7 and v5.2.6 all landed in September 2026, at 2026-09-24, 2026-09-18 and 2026-09-16 respectively, so the release cadence in that window is roughly weekly. The go.mod targets Go 1.26.0 and pins a wide dependency set, including the UnPoller-maintained UniFi client library at v6.1.2. Upgrading UnPoller therefore means tracking that library as well, since controller compatibility largely lives there.

Operationally, the upgrade cost is low if you deploy the binary or the container: the Dockerfile has a single entrypoint and a healthcheck, and the config file is copied in at build time. It is higher if you build from source, because the Makefile pulls build tools over the network, including github.com/davidnewhall/[email protected] for man page generation and github.com/akavel/rsrc for Windows executables. Those are build-time dependencies, not runtime ones.

The licence is MIT, stated in the repository and in the README's copyright section, which covers 2018-2020 David Newhall II. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are kept. That is a summary of the licence text, not legal advice, and if you are redistributing UnPoller inside a product you should read the LICENSE file in the repository rather than this paragraph. Note that the licence covers UnPoller, not the UniFi controller or the Grafana dashboards hosted on grafana.com, which carry their own terms.

Editorial conclusion

Adopt UnPoller if you already operate a UniFi controller and want its data in InfluxDB or Prometheus with the supplied Grafana dashboards. Do not adopt it if you have no controller running continuously, since the README states the application requires that. Before installing, verify the controller version against the supported list in the README and confirm your UnPoller version can authenticate against it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. unpoller/unpoller on GitHub