Telemetry

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, extension 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 extension IDs and versions during extension 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 Athas Does Not Send

Athas 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

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 extension 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.