Telemetry
What Ezhuthaani sends, what it does not send, and how local telemetry delivery works.
Ezhuthaani keeps telemetry intentionally narrow.
Anonymous usage telemetry is off by default. If you turn it on, Ezhuthaani sends anonymous operational metadata so we can understand app health, integration behavior, and crashes.
Ezhuthaani still sends a smaller update-check signal so the updater can work and we can measure release health by version and platform.
What Ezhuthaani Always Sends
Ezhuthaani 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, orfailed - Available version when an update exists
Ezhuthaani also keeps basic lifecycle context locally, including install date, previous version, and launch count, and attaches that context to telemetry events.
What Ezhuthaani Sends When Enabled
When anonymous usage telemetry is enabled, Ezhuthaani 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 Ezhuthaani Does Not Send
Ezhuthaani 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
Ezhuthaani 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
- Ezhuthaani 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 Ezhuthaani can retry delivery on a later launch if a send fails.
Crash Reporting
Crash reporting is part of Ezhuthaani anonymous usage telemetry.
If the desktop runtime hits an unhandled error, Ezhuthaani 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:
- Open Settings
- Go to Advanced
- Open Telemetry Log
The log shows queued events, delivery attempts, failures, and clears.
You may see entries like:
queuedsentfaileddroppedcleared
Clearing the telemetry log removes local history entries. It does not disable telemetry and it does not delete pending queued events.
Settings
Ezhuthaani 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
Ezhuthaani 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.