CLI telemetry
The evlog CLI records one anonymous wide event per run, so we know which commands people use and which ones error. It is the same telemetry toolkit evlog ships for your own CLIs, pointed at itself.
What init records
evlog init asks more questions than the other commands, so it records the answers — which lets the flow lead with the options people actually pick and drop the ones nobody does.
| Recorded | Example |
|---|---|
| Framework, development sink, sampling preset | nuxt, fs, balanced |
| One flag per destination, extra and enricher chosen | initProdAxiom: true |
| Counts | files written, manual steps left, doctor failures |
| Whether an offer had anything behind it | initHadRepeatedErrors: true |
Every string is an id from the CLI's own catalog and is checked against an allowlist before it is sent — an undeclared value is dropped rather than transmitted. Your service name is never recorded, nor package names, paths, or anything read out of your source. The last row says only whether the scan found something, never what it found.
What map records
evlog map records the shape of a scan: the score and its grade, how many entry points there were and how many are instrumented, partial, dark or exempt, which framework was detected, and whether a --min-score or --baseline gate failed the run.
| Recorded | Example |
|---|---|
| Score and grade | mapScore: 72, mapGrade: good |
| Entry point counts by coverage | mapEntryPoints: 34, mapDark: 9 |
| Per rule: how many entry points failed it, how many waived it | mapFailWideEvent: 6, mapSuppressedWideEvent: 2 |
| Which gate ran, and whether it failed | mapGate: baseline, mapGateFailed: true |
Rule ids are the CLI's own closed set and are already public. Everything read out of your source is a count: no route path, no file name, no project name, no snippet.
See what is collected
evlog telemetry status
The command prints whether telemetry is on, where its data directory is, and the full disclosure table — every field, its type, and what it is for. The disclosure is generated from the code that sends the event, so it cannot drift from what actually goes over the wire.
Telemetry: enabled (preference: enabled)
Data directory: ~/.config/evlog-cli/telemetry
What is in an event
One event per run, with the command name, how long it took, whether it succeeded, and the error code when it did not. Alongside that: the Node version, the OS and architecture, whether the run was in CI and on which provider, whether stdout is a TTY, and whether an AI coding agent was driving it.
Flags are recorded as the ones you actually passed. Booleans and numbers keep their value; a string value is recorded as <set> rather than by content, unless the flag is explicitly allowlisted. Positional arguments are never recorded at all, and a flag left at its default is not recorded either — evlog map on its own sends an empty flags object. The machine id is a hash, and it is omitted entirely in ephemeral CI.
Turn it off
Any one of these is enough:
# persisted preference
evlog telemetry disable
# per-run, or in a shell profile
EVLOG_TELEMETRY=0 evlog map
# the cross-tool standard, respected everywhere
export DO_NOT_TRACK=1
evlog telemetry disable also purges anything that had been queued and not yet delivered. evlog telemetry enable turns it back on.
Inspect before trusting
To see exactly what a run would send, without sending it:
EVLOG_TELEMETRY_DEBUG=1 evlog map
The would-be payload is printed to stderr.
Commands
| Command | What it does |
|---|---|
evlog telemetry status | Current state, data directory, and the full disclosure |
evlog telemetry enable | Enable anonymous usage telemetry |
evlog telemetry disable | Disable it and purge undelivered data |
doctor
Diagnose an evlog setup — Node version, project resolution, the installed evlog version, the detected framework, and whether local logs are being written.
agents
Teach the AI agents working in your repository how to use evlog — a short block of conventions in AGENTS.md, plus the published agent skills installed through npx skills.