The 300-monitor wall is real, and sharding Uptime Kuma is a bill you keep paying

A broadcast dashboard has two variables in its cost curve, not one. If full state goes to every connected browser ^[2], the work is monitors multiplied by open tabs, and it accrues whether or not anyone is looking at the check that just flipped. The wall-display in the NOC counts. So does the tab someone left open on Friday.

The design Cairn offers against that is not the probe architecture the post leads with. It is the ordering: the OpenAPI spec was frozen before the first line of product code, and the dashboard is described as the first API client rather than a privileged one ^[7]. A client that asks for the rows it renders has a cost tied to the screen. A client that is fed state has a cost tied to the estate. That is the whole difference, and it is a frontend contract, not a distributed systems trick.

The control plane and probe split ^[14] solves a different problem, which is where checks run: probes register over gRPC, pull assignments, and in solo mode compile into the same binary so you never see them ^[15]. Useful if you need a check from inside a VPC. Irrelevant to the browser. Two problems are being sold as one.

Then there is the write path nobody costs out. Intervals go down to 20 seconds ^[10], and at the headline figure of 5,000 monitors ^[17] the floor interval is 250 heartbeats a second ^[2]. The default storage is SQLite, one container and one volume, no Redis and no broker ^[8]. The stack also lists Postgres with Timescale as an option ^[9]. Those are two different deployments wearing one docker run command, and the post does not say where the line is.

What sharding costs is worth naming precisely, because the import tool is aimed squarely at it: point it at several Kuma databases and it merges them into one install ^[12]. Per shard you keep a second copy of notification routing in step with the first. Dependency-aware suppression, the thing that stops one dead router paging you forty times ^[11], cannot reach across a boundary the product does not know exists. Each shard publishes its own status page. None of that shows up in a capacity chart, and all of it shows up at 3am.

The honest ledger on the other side: Kuma has 88k stars and roughly 40 monitor types ^[1], Cairn enumerates about nine kinds of check ^[3] and has one maintainer several months in ^[4]. The 5,000 figure sits in the headline; no measurement of it appears in the post ^[5]. And the new operational trap is cairn.key, the file that encrypts saved passwords and tokens, without which the database has holes in it ^[13]. Restore drills that only cover the .db file will pass and still lose your credentials.

For anyone already running a second and third Kuma ^[3], the artefact that matters is the --dry-run output of the import ^[12]. It is the only document that tells you which of your checks survive the move, and it costs nothing to generate before you decide.