Telemetry

The hosted service is not where most instances run. Without a snapshot the project has no way to tell whether a release is still in use before dropping support for it, whether a feature is worth keeping, or how often webhook deliveries and agent runs fail outside a developer machine. The snapshot answers those questions with counts and yes/no flags, not with your data.

• instance idA random uuid, generated once for this instance and stored in its database. It is not derived from your domain, your keys, or anything else in the instance.
• installed onThe day the instance was installed, taken from the timestamp of its first database migration.
• versionThe running version.
• runtimeBun version, OS and architecture, Postgres major version, and whether it runs in Docker.
• sizeHow many users, projects and issues there are, plus how many users signed in and how many issues were created in the last 30 days. All of it as ranges (6-20, 101-1000), never exact numbers.
• featuresWhether each of these is used at all, as yes/no: initiatives, note boards, dashboards, saved views, custom fields, label groups, project actions, attachments.
• integrationsWhether each of these is set up and switched on, as yes/no: email, Google sign-in, Telegram bot, webhooks, API keys, MCP, per-project integration credentials.
• ai agentsHow many agents there are, how many runs in the last 30 days (as ranges), and whether schedules are used.
• failure ratesThe share of webhook deliveries and of agent runs that failed in the last 30 days.

Names of anything: project keys, issue titles, descriptions, comments. Email addresses, user names. Webhook URLs, agent prompts, credentials, environment variables, file contents, logs, error messages. Exact counts.

No third-party analytics service is involved, and the snapshots are not sold, shared or used for advertising.

The first snapshot goes out when the worker starts, so an instance that is set up and removed the same hour is still counted once. After that each instance picks one minute of the day at random and keeps it, then reports once a day from that minute on. That spreads the traffic instead of every instance reporting at midnight UTC.

A send that fails is retried with a growing delay for five attempts, then once an hour. The worker logs each failure and carries on with its other work.

Set either variable in your instance’s .env:

TELEMETRY_DISABLED=1
# or the cross-tool convention, read the same way:
DO_NOT_TRACK=1

Any value except 0 (and an empty one) turns telemetry off. Nothing is sent after that, and no instance id is generated.

To read the exact body before each send, turn on debug logging and watch the worker’s output:

TELEMETRY_DEBUG=1

The code that builds and sends the snapshot is part of the repository, so the payload can also be read there.

Snapshots go to telemetry.itsaplan.dev, a collector operated by the project.

This page describes self-hosted instances. Data handling for the hosted service is covered by the privacy policy, and the same description ships with the source as TELEMETRY.md.