Skip to main content
The plugin sends a small, anonymous usage report once per day so the maintainer can see which Payload and plugin versions are in use and which features are worth supporting. It is opt-out and disclosed: a one-time notice prints to your server logs on first run. No secrets, IPs, keys, zone/library/bucket names, hostnames, countries, file paths, or collection names ever leave your server.

What is collected

Every report is a single JSON document with these fields:

Feature flags

features is a flat map of booleans derived from your resolved configuration. It records only whether a capability is on, never any value tied to it:

How projectId is derived

projectId is a one-way, irreversible hash:
payload.secret is used only as a salt and is never transmitted — it is high-entropy and private, so the digest cannot be reversed. This mirrors how Payload derives its own telemetry id. rawSource is the first available of, reported as projectIdSource:
  1. git — the repository’s remote.origin.url
  2. packageJSON — your app’s package.json name
  3. serverURLpayload.config.serverURL
  4. cwd — the process working directory
Only the salted hash is sent — never the git URL, package name, or server URL themselves.

What is never sent

No IP address, no payload.secret, no API keys, no zone / bucket / library / domain names, no file paths, no collection names, no country codes, and no URL-transform internals. features carries booleans only.

Opting out

Telemetry is disabled automatically if any of these is true:
  • payload.config.telemetry is false (the host’s own Payload opt-out)
  • the plugin’s telemetry is false
  • the BUNNY_TELEMETRY_DISABLED or DO_NOT_TRACK environment variable is set to a truthy value
  • a CI environment is detected
  • NODE_ENV is test
To opt out explicitly:
payload.config.ts
Or via the environment (respects the cross-tool Console Do Not Track standard):

Sending to your own collector

Pass an object with an endpoint to point reports at a collector you control:
payload.config.ts

Transport

Reports are fire-and-forget: they never block boot, never throw, and are capped at a 2-second timeout — a telemetry failure can never affect your application. At most one report is sent per project per UTC day (best-effort, via a timestamp in the OS temp directory).