How CrashPilotX handles your data.

Two kinds of data leave a monitored machine, both sent directly to your own Supabase project (see "Where your data lives" below):

• Heartbeats, roughly every 60 seconds: CPU/memory/disk/network/GPU load, agent health, and (on a slower cadence) hardware and dmesg summaries. This is small, structured JSON.
• Crash reports, only when a crash is detected: a root-cause analysis plus a trimmed evidence summary, kernel log excerpts, relevant journal snippets, and system context at the time of the crash.

The full raw telemetry the agent collects locally (complete dmesg buffer, full journal history, SMART/thermal dumps) is not uploaded. Only the trimmed summary needed to explain a crash is sent; the rest stays on the machine in the agent's local SQLite database.

Each system has a retention setting, 30 days by default and adjustable from 1 to 365 days in its system settings, and a storage budget (20 MB by default, 5 to 200 MB) that sets how many alerts and reports it keeps. In practice:

• Metric and heartbeat history is kept for at most 7 days, whatever the retention setting.
• Crash reports and alerts are kept for the retention period. Resolved or ignored reports go after 14 days, and resolved alerts after 7, if retention is longer.
• Past the budget's row limit, the oldest resolved or ignored reports and the oldest alerts are removed first. Open reports are never removed for space.
• A retired system is deleted with all of its history once its retention runs out. For an ephemeral node, that is its join token's retention, 7 days by default.

Pruning runs at most hourly, when the system sends new data, so a system that has gone quiet keeps its history until it reports again, is retired, or is deleted.

Before telemetry is used for crash detection, sent to an AI provider, or uploaded anywhere, the agent scans it for text that looks like a credential and replaces it with a labeled placeholder (e.g. [REDACTED:github_token]). This runs locally, on every collection cycle, before anything leaves the machine.

Patterns currently detected include:

• Cloud provider keys (AWS access keys, Google API keys)
• Service tokens (GitHub, Slack, Stripe, OpenAI, Anthropic)
• PEM-format private key blocks and JWTs
• Bearer tokens and HTTP basic-auth credentials embedded in URLs
• Any password= / token: / secret=-style key-value pair with a non-trivial value

This is pattern matching on text that looks like a secret, not a guarantee every credential is caught. Treat it as a safety net, not a substitute for not logging secrets in the first place. When a report has redactions, its detail page shows a "secrets redacted" badge naming exactly what was found, so nothing is silently hidden.

AI-powered root-cause analysis is opt-in. It only runs if you set an Anthropic API key on the agent. Without one, CrashPilotX still works, it falls back to a fully local, built-in heuristic analyzer, and nothing is sent to any AI provider at all.

When AI analysis is enabled, the redacted telemetry summary for the current crash is sent to Anthropic's Claude API for that one analysis request. Per Anthropic's API terms, data sent through the API is not used to train Anthropic's models by default. CrashPilotX itself never uses your data to train anything.

The only third party that can ever receive your telemetry is Anthropic, and only when you've configured AI analysis as described above.

Everything else (heartbeats, crash reports, metric history) is written directly from the agent to your own Supabase project. CrashPilotX does not operate a central database or receive a copy of your data; the dashboard you're using right now talks only to the Supabase project you configured when you set it up.

All traffic between the agent, the dashboard, and Supabase is encrypted in transit (HTTPS/TLS); the agent's install script refuses to configure a plain-http Supabase URL. Data at rest is encrypted using Supabase's standard infrastructure-level encryption for your project's database.

You can delete a single incident report at any time from its detail page, using the Delete button in the incident ownership panel. This removes the report and its activity history permanently. Deleting a system from the Systems page removes that system and every log table tied to it (heartbeats, metric history, alerts, crash reports) in one operation. Both actions run immediately and are not recoverable, since there's no separate backup layer to restore from.