# Telemetry

Source: https://athas.dev/docs/telemetry

What Athas sends, what it does not send, and how local telemetry delivery works.

Athas keeps telemetry intentionally narrow.

Anonymous usage telemetry is **off by default**. If you turn it on, Athas sends anonymous operational metadata so we can understand app health, integration behavior, and crashes.

Athas still sends a smaller update-check signal so the updater can work and we can measure release health by version and platform.

## What Athas Always Sends

Athas always sends a small update-check payload:

- Anonymous install ID stored locally on the device
- App version
- Platform and CPU architecture
- Update-check status such as `available`, `up_to_date`, or `failed`
- Available version when an update exists

Athas also keeps basic lifecycle context locally, including install date, previous version, and launch count, and attaches that context to telemetry events.

## What Athas Sends When Enabled

When anonymous usage telemetry is enabled, Athas may also send:

- Heartbeat events from active app sessions
- Installed integration IDs and versions during integration sync and update checks
- Extension update candidates and update counts
- Extension install, uninstall, and update events
- Crash reports for runtime failures and unhandled errors

## What telemetry does not send

Usage telemetry does **not** send:

- File contents
- Source code
- Prompt contents
- Chat messages
- Terminal contents
- Secret values from your environment
- Workspace paths
- Full project structure or framework-level product analytics

## How Data Is Sent

Athas stores telemetry in a local queue and sends it over HTTPS:

- Telemetry initialization starts about 10 seconds after app launch
- The queue flushes every 5 minutes
- Athas also flushes early when 50 events are waiting
- The local queue is capped at 200 events; oldest events are dropped first

Crash reports are queued locally too, so Athas can retry delivery on a later launch if a send fails.

## Crash Reporting

Crash reporting is part of Athas anonymous usage telemetry.

If the desktop runtime hits an unhandled error, Athas records diagnostic metadata such as:

- Error message
- Stack trace when available
- Crash source such as bootstrap failure, window error, or unhandled rejection
- App version, platform, and architecture

This helps us fix stability issues without collecting project contents.

## Telemetry Log

You can inspect recent local telemetry activity inside the app:

1. Open **Settings**
2. Go to **Advanced**
3. Open **Telemetry Log**

The log shows queued events, delivery attempts, failures, and clears.

You may see entries like:

- `queued`
- `sent`
- `failed`
- `dropped`
- `cleared`

**Info:**

  Clearing the telemetry log removes local history entries. It does not disable telemetry and it
  does not delete pending queued events.

## Settings

Athas currently exposes a single usage telemetry toggle in **Settings → Advanced**.

That toggle covers:

- Heartbeats
- Extension metadata and lifecycle events
- Crash reports

Update checks remain operational even when usage telemetry is off.

## Why This Exists

Athas uses telemetry for product operations, not deep behavior profiling.

The goal is to answer practical questions such as:

- Are updates working?
- Are integration installs and update checks working?
- Are crashes clustered around a specific release or platform?
- Are desktop sessions alive after rollout?

If that is all working, we do not need heavier analytics.

## Other online features

These statements describe telemetry. Choosing hosted AI sends the relevant prompt/context to its
service; sharing and cloud session sync upload the content described in [Share to Web](https://athas.dev/docs/sharing).
Connected accounts also make service requests. Read [Security](https://athas.dev/security) and each feature guide
for its own data boundary rather than applying telemetry exclusions to every online feature.