Monitoror

Last reviewed Sep 13, 2026 · 761 words

One binary, about 64 MB of RAM, one JSON file of tiles, and a browser pointed at a TV: that is the whole of Monitoror. It is not an alerting system, it will not page you, it keeps no history, and its development pace has slowed since the 2019 launch. Treat it as a display layer over monitoring you already run, not as the monitoring itself, and it is one of the cheapest ways to put a wall of green and red squares in a room.

Two files and you are done

The core reads a .env file, the UI reads a config.json. The .env holds the port and any credentials for services the tiles talk to, using the MO_ prefix:

MO_PORT=8080
MO_MONITORABLE_GITHUB_TOKEN=ghp_yourtoken
MO_MONITORABLE_JENKINS_URL=https://ci.example.com

The tile file describes the board:

{
  "version": "2.0",
  "columns": 4,
  "tiles": [
    { "type": "PING", "label": "Router", "params": { "hostname": "192.168.1.1" } },
    { "type": "PORT", "label": "Postgres", "params": { "hostname": "db.lan", "port": 5432 } },
    { "type": "HTTP-STATUS", "label": "Nextcloud", "params": { "url": "https://cloud.example.com/status.php" } },
    { "type": "GITHUB-CHECKS", "label": "app main", "params": { "owner": "me", "repository": "app", "ref": "main" } }
  ]
}

Start the binary (or the monitoror/monitoror image with both files mounted), then open http://host:8080/?configPath=./config.json. Tiles refresh on their own schedule, a failing check turns red, a running build pulses, and the board rearranges itself to the column count you set. The query string is how one core serves several boards: a different configPath per TV.

The tile catalogue is short

That is the list, and the catalogue's "limited monitor types" con is exactly right. No SNMP, no Docker container state, no certificate expiry, no database queries. The escape hatch is HTTP-FORMATTED: point it at any JSON endpoint and pull a value with a JSONPath-style key, which is how people surface a Home Assistant sensor or a Prometheus query result on the board without a native tile.

What it will not do, on purpose

There is no notification channel of any kind, no status history, no public status page, no user accounts on the UI, and no multi-tenancy. A tile that goes red at 3 a.m. and green at 3:10 leaves no trace. The project is a radiator for a room where people already look at the wall; that is a legitimate product, but it means Monitoror is the second monitoring tool you install, never the first. The homelab uptime monitoring piece covers what the first one should be.

Where it fits: on top of Uptime Kuma or Gatus

The pattern I like is to let Uptime Kuma or Gatus do the checking and alerting (the Gatus vs Uptime Kuma page picks between them), and let Monitoror be the big-screen view. Gatus exposes its results as JSON, so a handful of HTTP-FORMATTED tiles turn its endpoint list into a wall. Add the CI tiles for the repositories the team ships from, put the TV in the room, and the two-tool combination costs under 200 MB of RAM in total.

Activity on the repository is the honest risk. Releases are infrequent, issues sit, and a new CI provider will not get a tile any time soon. Because the whole thing is a static UI plus a small Go core with no state, that matters less than it would for a database-backed service: a stale Monitoror keeps working until a tile's upstream API changes.

What I'd do

Run Uptime Kuma as the real monitor with notifications, then Monitoror on the same host with one config.json per screen, mounted read-only, refreshing from Gatus or Kuma's JSON plus the GitHub checks tiles. Give it the 64 MB, leave it alone, and accept that if the project ever stalls completely the replacement is any browser kiosk pointed at whichever dashboard tool you prefer. For a wallboard that a team glances at, it is still the least effort per square metre of screen.