Product telemetry is the small set of anonymous, content-free events a deployment sends to Chickpea’s maintainers to measure adoption. Where usage records and audit events stay inside the state your deployment owns, these events are the one product signal that leaves it. This page lists the six events and their properties, what is never sent, how installation identity and delivery work, and how to switch telemetry off.
Telemetry is enabled by default. Chickpea runs outside any infrastructure its maintainers can observe, so the events answer four questions: whether installations reach a successful run, whether connections and schedules are adopted, whether installations return, and whether the project is growing. They are advisory only and are never used for billing, entitlements, security decisions, reliability alerts, or customer-facing state.
What every event sends
| Property | Value |
|---|---|
distinct_id |
A random UUID standing for one installation. |
timestamp |
The UTC time when Chickpea attempted delivery. |
schema_version |
1. |
runtime_target |
cloudflare or node. |
app_version |
The package version compiled into the release. The current pre-release reports 0.0.0. |
telemetry_environment |
production, development, or test. |
$process_person_profile |
false, so PostHog creates no person profile. |
$geoip_disable |
true, so PostHog derives no location from the request IP. |
Events that name a workspace or an Agent carry workspace_key and agent_key instead of real IDs. Each is the first 16 bytes of a domain-separated HMAC-SHA-256 value, encoded base64url and prefixed ws_ or agent_. The key that produces them never leaves the deployment, so the same workspace looks unrelated across two installations.
The six events
This list is exhaustive. Chickpea has no browser autocapture, session recording, exception capture, or catch-all event API, and no analytics SDK ships in the deployment. The field-level contract behind this table lives in TELEMETRY.md in the product repository.
| Event | When it fires | Event-specific properties |
|---|---|---|
workspace_connected |
A Slack workspace first reaches a healthy connected state. | workspace_key; transport_mode (direct or gateway) |
agent_created |
A user-created Agent is committed. Nothing is seeded, so every Agent on a fresh install emits it. | workspace_key; agent_key; surface (admin, slack, mcp, other) |
connection_ready |
A connected account first becomes ready for an Agent to use. | workspace_key; agent_key; connection_kind (managed, mcp, api); owner_kind (team or member); surface |
schedule_created |
A new schedule and its authority binding are committed. | workspace_key; agent_key; cadence_kind (one_time or recurring); destination_kind (channel or direct_thread) |
run_completed |
An interactive delivery or a scheduled run reaches a terminal state. | workspace_key; agent_key; agent_origin (seeded or user_created); trigger_kind (interactive or scheduled); outcome (succeeded, no_op, failed) |
installation_active |
Once per UTC day, appended to one other event. | workspace_count; user_agent_count; ready_connection_count; enabled_schedule_count |
connection_ready does not identify the provider, toolkit, account, or owner. schedule_created carries no task, expression, time zone, destination, or recipient. run_completed carries no output, duration, token count, model, failure class, or error text. Every count on installation_active is reduced to 0, 1, 2_4, or 5_plus before delivery, so a snapshot says “two to four Agents”, never how many.
What is never sent
- No conversation content. No Slack messages, prompts, instructions, memory, attachments, transcripts, or model input or output.
- No work detail. No tool names, tool arguments, tool results, code, repository contents, schedule tasks, connection data, or connector provider names.
- No diagnostics. No error messages, stack traces, HTTP response bodies, operational logs, performance timings, token counts, or model names.
- No identifiers. No Slack workspace, channel, user, user-group, message, or thread IDs, and no Chickpea Agent, connection, schedule, or run IDs.
- No people or places. No names, email addresses, usernames, organization names, hostnames, URLs, IP-derived location, headers, tokens, credentials, or secrets.
- No web analytics. No page views, clicks, session recordings, cookies, device fingerprints, or person profiles.
Installation identity
On the first eligible event, Chickpea generates a random UUID and a random 32-byte HMAC key and stores them in its own settings store under telemetry.identity.v1. Neither value is derived from a machine, a Slack account, a network, a hostname, or customer data. The UUID becomes distinct_id; the key stays local and only produces the pseudonyms above.
The daily gate lives separately under telemetry.active_day.v1 and holds one value: the last claimed UTC date. The day is claimed atomically before any inventory read, so concurrent activity cannot produce two snapshots, and a snapshot that fails is not retried.
Deleting telemetry.identity.v1 while telemetry is disabled resets the anonymous identity, and the next eligible event creates an unrelated UUID and key. Delete telemetry.active_day.v1 as well if the installation should be eligible for a fresh snapshot on the same UTC day. Events already stored by PostHog are not linked to the new identity and are not deleted by a local reset.
Delivery
Each product outcome is sent immediately as an HTTPS POST to the fixed endpoint https://us.i.posthog.com/batch, PostHog US Cloud. The batch holds that event and, when the daily gate is won, one installation_active event. The compiled project token grants ingestion only; it is not a secret and cannot read project data.
A request is capped at 32 KiB and dropped rather than trimmed if it would exceed that, has a five-second deadline, follows no redirects, reads no response body, and is never retried. Failures are swallowed, and cannot change an HTTP response, a Slack acknowledgement, an Agent result, a state transition, a retry decision, or a scheduled-run outcome.
Like any HTTPS request, the network peer receives ordinary connection metadata: source IP, TLS and HTTP metadata, timing, and approximate request size. The Chickpea PostHog project discards source IP data, and GeoIP enrichment is disabled both on each event and in the project’s transformation settings. Network intermediaries your host or platform selects may still process transport metadata under their own policies.
Turning telemetry off
Set either variable to 1, true, or yes, in any case. DO_NOT_TRACK is the common cross-tool opt-out; CHICKPEA_DISABLE_TELEMETRY covers Chickpea product telemetry only. Restart the deployment after changing its environment.
| Target | Where to set it |
|---|---|
| Cloudflare | A Worker variable in the dashboard, or npx wrangler secret put DO_NOT_TRACK |
| Node | The process or service environment that starts Chickpea |
Opting out is total. The telemetry composition returns a no-op before it reads or creates identity state, reads adoption inventory, generates randomness, starts a timer, makes a network request, or writes a telemetry log. Nothing is buffered for later delivery.
Environment labels
CHICKPEA_TELEMETRY_ENVIRONMENT accepts production, development, or test. It labels events; it never disables them. With the variable unset, NODE_ENV supplies the label when it holds one of those three values, and otherwise Cloudflare labels events production and Node labels them development. A value outside the three resolves to development, so a mislabelled deployment cannot enter the production measurement set.
Why it works this way
The privacy boundary is structural rather than editorial. A closed event union and a per-event serializer rebuild every payload from an explicit property allowlist, so an unknown event name or property is discarded at the boundary instead of forwarded. An unrecognised enum value falls back to a documented one: an unknown surface becomes other, an unknown outcome becomes failed. Raw workspace and Agent IDs exist only long enough to compute the installation-local pseudonyms.
Capture points sit after committed milestones and terminal settlements, never in logging or exception paths, which keeps operational text out of the input entirely. Adding or changing an event or a property requires an allowlist change, contract tests, and an update to the telemetry contract in the same reviewed change, so the published list cannot drift from the code.
What is not covered
- Telemetry says nothing about your other traffic. Requests between your deployment and your model provider, Slack, or connected services are outside this page.
- An opt-out is not a deletion request. Events already stored by PostHog remain; the local identity reset only stops future events from joining them.
- The integrity checks are not a security control. Maintained queries flag unknown event names or person profiles, which detects public-token abuse but is not treated as protection.
installation_activeis coarse by construction. Bucketed counts cannot be reversed into an exact number of workspaces, Agents, connections, or schedules.
Next steps
- Security model: the guarantees the rest of the deployment enforces, and the mechanism behind each.
- Environment variables: the telemetry variables alongside every other variable an operator may set.
- Configure your deployment: where to set variables on Cloudflare and on Node.
- Security: the rest of this section, including what is stored where.