Load-Test an Uptime Platform Before Adding 12,000 Targets

Calculate the workload before choosing hardware

For 1,000 customers with 12 services each, the number of targets is 12,000. A 60-second interval produces 200 scheduled checks per second. That is 17.28 million observations per day if each check writes one observation. Retention, indexes, aggregation, and compression determine actual storage; do not multiply by an invented fixed row size.

If checks occupy a connection for ten seconds during an outage, the same arrival rate implies roughly 2,000 concurrent in-flight checks before retries. This planning estimate assumes steady arrivals. Synchronized startup and retry bursts can be worse. Document limits for outbound sockets, DNS, TLS handshakes, database connections, and the target systems themselves.

Build a controlled target farm

Use endpoints you own in an isolated benchmark environment. Generate stable target identifiers and several response behaviors: fast success, slow success, timeout, redirect chain, TLS error, and invalid content. Do not send a 12,000-target experiment to unrelated public websites.

Increase target count in steps, holding interval and retention constant. Run each stage long enough to include normal history cleanup, backups, and reconnects. A five-minute test against empty storage misses database growth and retention work. Include a soak test with representative history, while recording exactly how that history was produced.

Separate the checker from the control workflow

A responsive dashboard does not prove checks ran on schedule. Conversely, a slow history chart does not prove probing stopped. Compare fresh observations against a known test endpoint independently of the UI.

The Prometheus multi-target exporter pattern (opens in a new tab) illustrates separating target configuration from protocol probing. Evaluate that architectural option alongside the installed Uptime Kuma version; it does not establish a universal Kuma capacity ceiling. Community reports from different databases, hardware, and versions are useful hypotheses, not comparable benchmarks.

For inventory management, insist on an idempotent import or supported configuration workflow. A customer rename must not create duplicate checks. A removed service needs an explicit retirement event, not a silent disappearance from a hand-maintained list.

Test partitions before relying on shards

If splitting the workload, assign each target a stable shard owner and include shard identity in observations. Keep the shared dashboard from becoming the only place capable of announcing shard failure. Never assume several application instances may safely write one database unless that deployment model is supported by the specific application version.

Disconnect one shard and check that affected targets become unknown, with one monitoring-capacity incident. Restore it and measure catch-up without replaying thousands of obsolete notifications. Define acceptance limits before the test, including maximum detection delay, queue age, recovery time, and support workflow latency. Publish the measured environment with the result; “supports 12k” without that context is not a usable sizing statement.