> ## Documentation Index
> Fetch the complete documentation index at: https://manifest.build/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Data and telemetry
> What Manifest stores about your requests, what it never stores, and the anonymous daily report each self-hosted install sends. Includes the full field list and how to opt out.
Two separate things happen to data as requests flow through Manifest: what your own instance records for the dashboard, and what a self-hosted install reports back to the project. This page covers both.
## What Manifest stores
Manifest keeps metadata about each request: model, provider, tier, token counts, cost, latency, and a scrubbed error message. It does not keep the message bodies. Prompts and completions are never written to the database, inline image data is stripped out, and error text is scrubbed for secrets before it lands.
Your agents' conversations stay between you and the provider. The usage and cost views in the dashboard are built from that metadata alone. See [Observability](/docs/observability) for what that record looks like in practice.
## Anonymous telemetry
Once a day, each self-hosted install sends us a small anonymous report. That's how we know whether anyone's actually using the thing, and which providers are popular enough to deserve more work. It's aggregates, never content: no prompts, no messages, no keys, nothing tied to a user. Fifteen fields total.
This section applies to self-hosted installs only. Manifest Cloud has no
separate telemetry report — your usage is already in your own dashboard.
### What gets sent
| Field | Example | Purpose |
| ----------------------------------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `schema_version` | `1` | So the shape can grow without breaking old clients. Stays `1` for additive changes; bumps on breaking ones |
| `install_id` | random UUIDv4 | Count distinct installs. Generated once on first boot, persisted, never rotated |
| `manifest_version` | `5.47.0` | Version adoption across the fleet |
| `messages_total` | `1284` | Daily activity per install |
| `messages_by_provider` | `{"anthropic": 700, "openai": 500}` | Provider mix. Anything we don't recognize collapses to `"custom"`, so self-hosted provider names and URLs stay local |
| `messages_by_tier` | `{"default": 900, "batch": 300, ...}` | Routing tier usage |
| `messages_by_auth_type` | `{"api_key": 1200, "subscription": 84}` | API key vs. paid-subscription usage |
| `tokens_input_total` | `1_450_000` | Volume-weighted signal |
| `tokens_output_total` | `890_000` | Same |
| `cost_usd_total` † | `47.83` | Sum of `cost_usd` Manifest computed at routing time, rounded to cents. Lets us see real dollar throughput instead of guessing from token counts. `0` for Ollama-only / free-API installs |
| `cost_usd_by_provider` † | `{"anthropic": 30.50, "openai": 17.33}` | Per-provider split of `cost_usd_total`, rounded to cents. Same `"custom"` collapse rule as `messages_by_provider` — admin-configured BYOK pricing is never keyed by the raw provider name |
| `agents_total` | `4` | Configuration scale |
| `agents_by_platform` | `{"openclaw": 3, "hermes": 1}` | Which agent clients people use |
| `platform` | `linux` / `darwin` / `windows` | OS distribution |
| `arch` | `x64` / `arm64` | Architecture distribution |
† *Optional. Installs running older Manifest versions omit these fields; receivers should feature-detect on presence rather than on `schema_version`. Cost values are derived from the same `input_tokens` / `output_tokens` we already ship, multiplied by Manifest's per-model pricing table — no new data leaves the box, just a rolled-up dollar figure for what's already disclosed.*
### Never sent
Tenant IDs, user IDs, emails, API keys, prompts, message contents, model names, custom provider URLs, OAuth client IDs, hostnames, raw IPs. The ingest takes a SHA-256 of your IP and throws the original away; we keep the hash so we can rate-limit bad actors without knowing where they actually live.
### When
* Once every 24 hours, per install.
* The first report is delayed by a random 0–24h offset, so a fleet of containers rebooted together doesn't all hit the endpoint at the same minute.
* Off by default when `NODE_ENV != production`. Dev machines are never going to accidentally send.
* If the endpoint is down, we log it and try again on the next hourly tick. Your proxy keeps serving requests — the sender never gets in the way.
### Turning it off
Put this in your `.env` (or `docker-compose.yml`) and restart the container:
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
MANIFEST_TELEMETRY_DISABLED=1
```
The sender checks the flag before doing anything else. No database read, no DNS lookup, no request leaves the box.
### Sending it somewhere else
If you'd rather run your own fleet dashboard, point `TELEMETRY_ENDPOINT` at a URL you control:
```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
TELEMETRY_ENDPOINT=https://telemetry.mycompany.internal/v1/report
```
## Related
* [Observability](/docs/observability) — what the recorded metadata gets you
* [Environment variables](/docs/reference/environment-variables) — `MANIFEST_TELEMETRY_DISABLED` and `TELEMETRY_ENDPOINT` in context
* [Self-hosting with Docker](/docs/self-hosted) — where to put these variables