Usage Statistics

Sublarr can send opt-in, pseudonymous usage statistics to help prioritise development, gauge compatibility, watch fleet health, and show real-world adoption. It is off by default and sends nothing until you explicitly enable it.

Legal basis

The processing rests on your consent (Art. 6(1)(a) GDPR). Consent is opt-in, default off, and withdrawable at any time — there are no consequences for leaving it off or turning it back off later. Withdrawing your consent also erases the data already collected from your install (see Right to erasure).

The consent card in the app and the Usage statistics setting say the same: reports are linked by a random install ID, the IP address is not stored, and both link the privacy policy and name the controller, Dennis Wittke.

What is sent

A single ping, roughly once every 24 hours. Every field is an enum, a boolean, or a coarse bucket — never a raw count and never free text.

Stable core (always sent when enabled)

Field	Example	Why
`install_id`	random opaque id	De-duplicate installs and count active ones; generated locally, not derived from anything identifying. A restored database gets a new id, so a backup restored onto a second instance never reports as the original install; the opt-in choice is kept
`version`	`1.17.0`	Which versions are in use
`arch`	`amd64` / `arm64`	Platform split (e.g. Raspberry Pi adoption)
`db_backend`	`sqlite` / `postgres`	Deployment shape
`providers_enabled`	`["addic7ed"]`	Which providers are popular
`library_size_bucket`	`1k-10k`	Rough deployment size (a bucket, never an exact count)
`reported_at`	ISO-8601	When the ping was sent

Feature usage — `features`

Field	Example	Values
`translation_enabled`	`true`	boolean
`translation_backend`	`ollama`	`ollama` / `openai` / `none` (type only — never a model name or URL)
`media_server_type`	`emby`	`jellyfin` / `emby` / `plex` / `kodi` / `multiple` / `none`
`sonarr_connected`	`true`	boolean
`radarr_connected`	`false`	boolean
`standalone_mode`	`false`	boolean
`redis_used`	`true`	boolean

Environment — `env`

Field	Example	Values
`interface_language`	`de`	low-cardinality locale code
`auth_type`	`proxy`	`none` / `ui` / `proxy`
`update_channel`	`stable`	`stable` / `rc` / `beta` (derived from the version suffix)

Scale buckets — `scale`

Each value is a bucket on the same scale as library_size_bucket (e.g. <100, 100-1k, 1k-10k), never an exact count.

Field	Example
`series_bucket`	`100-1k`
`movies_bucket`	`<100`
`downloads_bucket`	`1k-10k`
`translation_jobs_bucket`	`<100`

Providers — `providers`

providers_enabled in the core cannot distinguish a deliberate choice from the default: an empty allow-list means “all registered”, so an install that picked nothing looks exactly like one that hand-picked every provider. This group separates the two, and adds which providers actually produce results.

Field	Example	Why
`curated`	`true`	Whether you restricted providers at all, or left the default
`enabled`	`["subdl"]`	Your explicit list — empty when `curated` is `false`
`delivering`	`["subdl"]`	Providers that produced at least one subtitle in the last 30 days

Provider names only. There is no per-provider count: a tally of how many subtitles each one produced would be a rough fingerprint of library size, and the payload rule is enum, boolean or bucket throughout.

Setup progress — `funnel`

Four yes/no markers for how far an install got between installing and its first subtitle. No counts, sizes or names. Current app versions send this group, but the collector does not store it — it is discarded on arrival.

Field	Example	Values
`setup_completed`	`true`	boolean — the onboarding wizard was finished
`library_scanned`	`true`	boolean — the library produced at least one wanted item
`scheduler_ran`	`true`	boolean — a scheduled job has run at least once
`first_download_done`	`false`	boolean — at least one subtitle was downloaded

Provider health

Field	Example	Why
`auto_disabled_count`	`0`	Fleet-health signal — how many providers auto-disabled, never which ones

Stored by the collector

Next to the fields above, the collector records per install the time of the first and the last report (first_seen, last_seen). That is what the 180-day retention below is measured against.

What is never sent

No hostname, no filesystem path, no series/movie title, no API key, no exact counts, and no per-user or per-library-content data.

Your IP address is necessarily transmitted when your install connects: stats.sublarr.de is reachable through Cloudflare, like the website (see the privacy policy). The collector itself does not store or log it. Which provider credentials an install has configured is deliberately not collected.

Retention

Installs: an install’s row is kept only while it stays active. If it stops pinging, it is deleted 180 days after its last activity (last_seen).
Aggregate snapshots: the public trend charts are built from daily snapshots that hold only anonymous aggregate counts (no install_id). Because they are anonymous, they are kept for 24 months.
Backups: deleted rows can survive in system backups for up to four weeks before those are overwritten.

Right to erasure

Because your install stores its own install_id locally, you can delete your data without knowing any server-side identifier. Turning the toggle off withdraws consent and fires POST /v1/forget {install_id}, which deletes your install’s row on the server. You never need to email anyone to be forgotten — though you still can (see the privacy policy). If that request fails (for instance because your server is offline at that moment), the row is removed by the 180-day rule instead.

Turning it on or off

New installs: you are asked once during onboarding.
Existing installs: you are asked once in the “What’s New” dialog after updating.
Any time: Settings → About → Usage statistics.

The public aggregate is shown at sublarr.de/stats.