Telemetry
Last updated: May 2026
What this page is
The Gostly agent collects a tightly-scoped set of anonymous usage signals so we can tell whether the install path actually works for the people who try it, and so we can find regressions early. It is on by default, and you can disable it at any time. This page is the source of truth for what is collected, who has access, and how long we keep it.
How to opt out
Set GOSTLY_TELEMETRY=off in the agent's environment (your .env or docker-compose.yml) and restart the agent. When opt-out is in effect, the shipper task is never spawned and no HTTP call is made to gostly.ai for telemetry.
When the agent boots it prints one line indicating the current state — for example: [gostly] Anonymous usage telemetry enabled (tier=free, scope=full). Disable: GOSTLY_TELEMETRY=off Details: https://gostly.ai/telemetry
What we never collect
- Request bodies or response bodies (recorded or mocked)
- Full URLs or hostnames the proxy sees
- Authorization headers, cookies, API keys, session tokens
- Raw service or mock names — only salted SHA-256 hashes leave the agent
- Customer IP addresses or user identifiers
- Your license key — only its SHA-256 hash is sent
Per-tier scope
| Signal | Free | Pro | Team | Self-host | Enterprise |
|---|---|---|---|---|---|
| Agent version, OS, architecture | yes | yes | yes | minimal | minimal |
| License validation success / failure counter | yes | yes | yes | license-only | license-only |
| Activation funnel (first request proxied / mock recorded / mock served) | yes | yes | yes | no | no |
| Mock fidelity p50 / p95 (upstream latency observations) | yes | yes | yes | no | no |
| Generation success / failure counters | yes | yes | yes | no | no |
| Validate-and-repair empty-template fallback counter | yes | yes | yes | no | no |
| Settings booleans (ENABLE_GENERATION, ENABLE_RAG, SMART_SWAP_ENABLED) | yes | yes | yes | no | no |
| IO error counter (severity only — never paths or contents) | yes | yes | yes | severity-only | severity-only |
| Per-service mock count (hashed service ID) | no | yes | yes | no | no |
| Distinct user count (workspace-level) | no | no | yes | no | no |
| Feature-gate hit counts | no | yes | yes | no | no |
| Default state | opt-out | opt-out | opt-out | opt-out (minimal) | opt-out (minimal + contractual) |
How service identifiers are protected
For Pro and Team tiers, the agent ships per-service mock counts so we can tell when a workspace has more than one service in active use. The service identifier is hashed client-side as SHA-256(service_id || ":" || SHA-256(license_key)) before transmission. Different licenses with the same service identifier produce different hashes, so we cannot join across tenants.
Where the data goes
Telemetry is shipped to https://gostly.ai/v1/telemetry/ingest and stored in our AWS account in us-east-1. The platform validates every payload against the per-tier allowlist on this page; payloads with unknown keys are rejected (HTTP 422) and never persisted.
Retention
Telemetry rows are retained for 90 days, after which they are deleted on a rolling basis. Aggregates derived from telemetry (e.g. weekly active agents, license validation success rate) may be retained longer for product planning, but they cannot be re-keyed back to the source rows after deletion.
Who has access
Access is restricted to Gostly engineering and the founder. Telemetry is never shared with third parties, never sold, and never used to drive ad targeting. Stripe billing data, account data, and telemetry are stored in separate tables with separate access policies.
Questions?
Email support@gostly.ai if anything on this page is unclear, or open an issue at github.com/NicRios/gostly-ai-proxy.