Telemetry & crashes

Active contributors: Veykril, miguelraz

Purpose

Zed collects crash reports (opt-out) and product analytics (opt-in). The system has three pieces: structured logging (zlog), an event pipeline (telemetry/telemetry_events), and a crash handler (crashes).

Crates

Crate	Role
crates/zlog	Structured logging macros
crates/zlog_settings	Runtime configuration for log filtering
crates/telemetry	Event batching + transport to the cloud
crates/telemetry_events	Schemas for every emitted event
crates/crashes	Native crash handler + Sentry integration
crates/etw_tracing	Windows ETW provider for low-overhead tracing
crates/ztracing, crates/ztracing_macro	Chrome-tracing-compatible profiler
crates/miniprofiler_ui	In-app UI for the trace data

Key abstractions

Item	Where	Description
log!, info!, warn!, error!	crates/zlog/src/zlog.rs	Macro front-end matching the log crate's API
Telemetry	crates/telemetry/src/telemetry.rs	The event collector + uploader
ClickhouseEvent	crates/telemetry_events/src/...	Wire format for events
InitCrashHandler	crates/crashes/src/crashes.rs	Installs the native crash handler at startup

How it works

graph TD
    App[zed app] -->|log!| zlog[zlog]
    App -->|telemetry::report_*| Tel[Telemetry]
    Tel -->|HTTPS batch| CH[Cloud event sink]
    App -->|crash| CH2[Crash handler]
    CH2 -->|HTTPS| Sentry
    Tracy[Tracy / ztracing] -.->|local profiler| Dev[dev workstation]
    OnDisk[on-disk log file] <-- zlog

Logging

zlog writes to a per-platform log file (see Debugging). It is filterable at runtime via env vars or settings. The macros support structured fields:

zlog::info!(target: "agent", "tool dispatched"; tool = name, args = args);

Telemetry

Events are opt-in. When enabled, crates/telemetry batches ClickhouseEvents and uploads them periodically. Each event type has a schema in telemetry_events so additions are reviewable.

Sensitive payloads (file contents, URLs of opened projects, AI prompts) are not included unless the user opts into "AI sharing" or similar. Scrubbing rules live alongside the schema definitions.

Crashes

crates/crashes::InitCrashHandler installs platform-native handlers at app start. On a crash, a minidump (or equivalent) is written and uploaded to Sentry.

The team has industrialised the post-crash loop:

• script/sentry-fetch <issue-id> — pull a crash by ID.
• script/crash-to-prompt <issue-id> — turn it into an AI-investigation prompt.
• .factory/prompts/crash/investigate.md and .factory/prompts/crash/fix.md — the templates the prompts use.

Tracing

ztracing produces Chrome-tracing-compatible JSON. The tracy Cargo feature on the zed crate wires up Tracy support if you have the desktop Tracy app. Linux/Wayland-friendly tracing is also wired through the same crates.

Integration points

• Inputs: every crate via macros / API.
• Outputs: local log files, the cloud event sink, Sentry.
• Settings: controlled by crates/telemetry_settings and the user's settings.json.

Entry points for modification

• New event kind — add to crates/telemetry_events, then call Telemetry::report_* in the right place.
• Log routing tweaks — crates/zlog/src/zlog.rs.
• Crash-prompt templates — .factory/prompts/crash/.

Related pages

• Debugging