Sensu Go

Last reviewed Sep 13, 2026 · 828 words

I would not start a new homelab on Sensu Go in 2026, and I would still recommend understanding it, because its pipeline model is the clearest explanation of what monitoring actually is that any open-source project has produced. Agents run checks, checks produce events, events flow through filters, mutators and handlers, and every one of those is a YAML resource you commit to git. The trouble is that Sumo Logic acquired Sensu in 2021 and the community around the 1,109-star open-source core has been shrinking since, which matters when you are choosing what to depend on for the next 5 years.

The pipeline in one paragraph

A check is a command with an interval and a list of subscriptions ("run check-disk-usage every 60 seconds on everything subscribed to linux"). The agent on each host runs it and sends the result to the backend as an event. Filters decide whether the event is interesting (only on state change, only during business hours, not if silenced). Mutators reshape it. Handlers do something with it: post to Slack, page, write metrics to InfluxDB. Every piece is a resource with type, api_version, metadata and spec, so the whole monitoring system is a directory of files and sensuctl create -f.

That is what "monitoring as code" means here, and it is more literal than Prometheus, where alert rules are code but the plumbing of who gets notified lives in a separate Alertmanager config.

Three binaries and 15 minutes

The backend bundles an embedded etcd, the API, and the web UI in one Go binary, with 512 MB of RAM as a realistic floor for a small fleet. In Docker:

services:
  sensu-backend:
    image: sensu/sensu:latest
    command: sensu-backend start
    ports:
      - "3000:3000"   # web UI
      - "8080:8080"   # API, sensuctl
      - "8081:8081"   # agent websocket
    volumes:
      - ./sensu-data:/var/lib/sensu
    restart: unless-stopped

On first start, initialise the admin user once with sensu-backend init and the SENSU_BACKEND_CLUSTER_ADMIN_USERNAME and SENSU_BACKEND_CLUSTER_ADMIN_PASSWORD variables set, then point the CLI at it:

sensuctl configure -n --url http://127.0.0.1:8080 \
  --username admin --password 'the-password' --namespace default

Agents install from a package or the same image, and connect outbound to port 8081 with --backend-url ws://backend:8081 and --subscriptions linux. The outbound-only agent is a real operational win over pull-based systems when hosts sit behind NAT or on a remote site.

A check as a file

The Bonsai asset index is the other clever part. Check plugins are downloadable assets the backend distributes to agents, so you never install a plugin on a host by hand:

type: CheckConfig
api_version: core/v2
metadata:
  name: check-disk
  namespace: default
spec:
  command: check-disk-usage --warning 80 --critical 90
  interval: 60
  publish: true
  subscriptions:
    - linux
  handlers:
    - slack
  runtime_assets:
    - sensu/check-disk-usage

sensuctl asset add sensu/check-disk-usage registers the asset, sensuctl create -f check-disk.yaml ships the check, and within 60 seconds every linux agent is reporting disk. Compare that to touching a Nagios config on every host and it is obvious why ops teams loved this.

Where it beats Prometheus, and where it does not

Sensu is better than Prometheus at status-style checks: is this process running, does this TLS certificate expire in 14 days, did the backup job exit 0. Those are commands with exit codes, and Sensu's model was built for them. Prometheus is better at everything numeric over time, has the vastly larger ecosystem, and pairs with Grafana without an adapter. Sensu can forward metrics, but nobody chooses it for that.

The awkward truth is that Checkmk and Icinga 2 cover the same status-check ground with larger active communities, and for a homelab a dozen Uptime Kuma monitors get you 80% of the value for 5% of the concepts. My notes on that trade-off are in the homelab monitoring post.

The licensing and momentum caveat

The open-source core is MIT, and it is complete enough to run everything above. A commercial tier has historically gated some features and larger entity counts, and since the acquisition, activity on the repository and in the community has thinned. The software still works, releases still appear, and the concepts have not aged. But an app with cons of "smaller community after acquisition" and "concepts take time to learn" is a hard sell for a new deployment when the concepts are the cost and the community is the safety net.

What I'd do

Running Sensu at work already: keep it, it is fine, and put the resources in git if they are not. Building fresh: Prometheus plus Alertmanager for metrics, Uptime Kuma or Gatus for up/down, and steal Sensu's idea of filters before handlers when you design your notification routing. Read the Sensu docs for the model, run something with more momentum for the next decade.