EzhuthaaniEzhuthaaniDocs

Search documentation

Find a guide or reference page.

DocsProject

Telemetry

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

On this page8 sections

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, or failed
  • 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:

  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

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.