Subarr installs that have opted in send a small daily payload. Aggregated stats live here. The dashboard view ships with v1.1; this page is the v1.0 placeholder so you can verify the pipe is live.
Installs we can positively identify as real: they reported a persistent
/data mount, or we have seen them on more than one day.
Until then this page counted every distinct install id, and that ran roughly 80 times too high. Subarr keeps its id in its database, and our own v1.0 and v1.1 setup docs told people to mount the wrong directory, so those installs lost the database on every restart and minted a fresh id each time. One person restarting forty times counted as forty installs. Of 23,426 ids ever seen, 22,840 had never sent a second ping.
The fix is subarr#473. The unfiltered numbers stay published below so this correction is checkable rather than something you have to take our word for.
Latest known subgen kind per install, last 30 days.
Per-integration usage across all installs, last 30 days.
Latest known subarr version per install, last 30 days (7-day numbers in parentheses where they differ). Genuine installs only, as above. Unfiltered, this chart was dominated by the very versions whose setup docs caused the id churn, which made it read as though almost nobody upgrades.
File paths, titles, IPs, hostnames, API keys, languages, anything user-fingerprintable.
These cannot reach this page because they cannot reach the database — the receiving worker
rejects payloads containing any of them with HTTP 400 (forbidden field: ...),
and the database schema has no columns for them.
The exact JSON payload your install sends is always visible in
Settings → Telemetry inside subarr. One-click opt-out in the same panel and
in the onboarding wizard.
Library-size distribution, scheduler-mode mix, walks-per-day cadence histogram, and the global provider success leaderboard. Endpoints are live now — frontend dashboards are coming.