# What Telemetry Data Is Collected by no-mistakes? A Complete Guide

> Discover what telemetry data no-mistakes collects. Learn about privacy-preserving event and page-view records, high-level identifiers, and what's excluded for your security.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: deep-dive
- Published: 2026-07-19

---

**The `no-mistakes` CLI transmits privacy-preserving event and page-view records to a configurable Umami endpoint, capturing only high-level identifiers such as run IDs, step names, status outcomes, and workload counts while never sending raw command arguments or personal data.**

The `no-mistakes` repository includes a lightweight, built-in telemetry client that aggregates operational insights without compromising user privacy. Telemetry data is collected through structured calls to `telemetry.Track` and `telemetry.Pageview` across pipeline steps and UI commands. Understanding exactly what telemetry data is collected by `no-mistakes` helps operators audit network activity and comply with internal privacy policies.

## Telemetry Architecture and Umami Endpoint

Telemetry in `no-mistakes` centers on a small Go client that forwards payloads to an Umami analytics instance. The default target is `https://a.kunchenguid.com/api/send`, though this can be overridden through environment variables.

### Client Initialization and Configuration

In [`internal/telemetry/telemetry.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/telemetry/telemetry.go), the `Default()` function bootstraps the telemetry sink. It reads three environment variables:

- `NO_MISTAKES_UMAMI_HOST` — the base URL of the Umami instance.
- `NO_MISTAKES_UMAMI_WEBSITE_ID` — the website identifier registered with Umami.
- `NO_MISTAKES_TELEMETRY` — when set to `off`, the function returns a `noopSink` that silently discards all events.

If telemetry is enabled, the client posts JSON payloads asynchronously using a one-second timeout and flushes gracefully at program exit via `telemetry.Close`.

## What Telemetry Data Is Collected by no-mistakes

The telemetry surface is deliberately narrow. All transmissions are categorized as either **pipeline events** (via `telemetry.Track`) or **page-view events** (via `telemetry.Pageview`).

### Event Payload Structure

Each call to `telemetry.Track` generates a JSON object of type `event`. The payload follows this exact shape as implemented in `telemetry.Client.newRequest`:

```json
{
  "type": "event",
  "payload": {
    "website": "<website-id>",
    "hostname": "cli",
    "title": "no-mistakes CLI",
    "url": "app://no-mistakes/<event-name>",
    "name": "<event-name>",
    "data": { "...fields supplied by the caller..." },
    "timestamp": 1721301234
  }
}

```

The **timestamp** is recorded as a Unix epoch in seconds. The **url** field is derived from the event name, and the **hostname** is always hard-coded to `cli`.

### Pipeline Events and Fields

Pipeline steps invoke `telemetry.Track(name, fields)` to emit discrete lifecycle events. Common event names observed in the source include `run`, `branch_created`, `committed`, `pushed`, `review`, `fix`, and `command`.

Callers supply an arbitrary key-value map through `telemetry.Fields`. Typical keys include:

- `run_id` — the internal UUID of the pipeline run.
- `step` — the pipeline step name, such as `review` or `fix`.
- `status` — `"success"` or `"failure"`.
- `error` — the error message, populated only when a step fails.
- `workload` — aggregated counts like changed files or net lines for local performance telemetry.
- `source` — the trigger source, which can be `agent`, `user`, or `auto`.

For example, a review step might record workload telemetry like this:

```go
telemetry.Track("run", telemetry.Fields{
    "run_id":   run.ID,
    "step":     "review",
    "status":   "success",
    "workload": map[string]int{"files": changedFiles, "lines": netLines},
})

```

### Page-View Telemetry

UI-driven commands emit page-view events through `telemetry.Pageview(path, fields)`. These events include a path string such as `/run` or `/sync` and optional contextual fields.

The following snippet, representative of UI command instrumentation, records a page view when a user invokes a sync operation:

```go
telemetry.Pageview("/sync", telemetry.Fields{
    "source": "cli",
})

```

## Where Telemetry Is Emitted in the Source Code

Telemetry is not centralized; it is emitted directly from the pipeline steps and UI layers that own the underlying action.

### Pipeline Step Instrumentation

- [`internal/pipeline/steps/intent.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/intent.go) calls `telemetry.Track` to emit `run` events that capture intent provenance and step outcome.
- [`internal/pipeline/steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/review.go) emits `review` events, including workload size metrics used for local performance telemetry.
- [`internal/tui/branch_sync.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/tui/branch_sync.go) emits a `command` telemetry event for UI-driven branch synchronization.

### Core Telemetry Implementation

The underlying transport is defined in [`internal/telemetry/telemetry.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/telemetry/telemetry.go), which exports `Track`, `Pageview`, `Default`, and the `noopSink` interface. Additionally, [`internal/telemetry/readgate.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/telemetry/readgate.go) implements a read-surface gate that throttles high-frequency, read-only telemetry to prevent noise.

## How to Disable Telemetry Entirely

Operators can completely disable data collection by setting the `NO_MISTAKES_TELEMETRY` environment variable to `off` (case-insensitive). When disabled, `telemetry.Default()` returns a `noopSink`, guaranteeing that **no network request** is ever made and no payload is serialized. This satisfies air-gapped or high-compliance environments where any external transmission is prohibited.

## Summary

- `no-mistakes` sends only high-level, privacy-preserving **event** and **page-view** records to an Umami endpoint.
- The payload includes static metadata (`hostname`, `title`, `url`), a Unix timestamp, and caller-supplied fields such as `run_id`, `step`, `status`, and `workload`.
- Telemetry is emitted from specific pipeline steps like [`internal/pipeline/steps/intent.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/intent.go) and [`internal/pipeline/steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/review.go), as well as UI handlers such as [`internal/tui/branch_sync.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/tui/branch_sync.go).
- Collection can be disabled entirely by setting `NO_MISTAKES_TELEMETRY=off`, which activates the built-in `noopSink`.

## Frequently Asked Questions

### Does no-mistakes collect raw source code or personal identifiers in telemetry?

No. The telemetry client is intentionally limited to aggregated counts, step names, and status outcomes. According to the `no-mistakes` source code, raw command arguments, file contents, and personal identifiers are never transmitted.

### How can I verify that telemetry is disabled in no-mistakes?

Set the environment variable `NO_MISTAKES_TELEMETRY=off` before running the CLI. When this variable is set, `telemetry.Default()` instantiates a `noopSink` whose `Track` and `Pageview` methods are empty, ensuring zero network activity.

### Which pipeline steps call telemetry.Track?

The primary call sites are located in [`internal/pipeline/steps/intent.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/intent.go) for run lifecycle events and [`internal/pipeline/steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/review.go) for review workload metrics. UI actions in [`internal/tui/branch_sync.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/tui/branch_sync.go) also emit telemetry events for command tracking.

### Where is the telemetry client configured in the codebase?

The client configuration and sink logic live in [`internal/telemetry/telemetry.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/telemetry/telemetry.go). This file defines the `Default()` constructor, environment variable parsing, the Umami payload builder, and the `noopSink` fallback used when telemetry is turned off.