Skip to main content
The Blaxel SDKs and Blaxel CLI use separate systems for usage reporting, error tracking, and workload observability.

Anonymous CLI usage reporting

When usage reporting is enabled in the CLI build and the local tracking preference allows it, the CLI sends the following events to PostHog to measure installation and setup outcomes. This reporting is separate from Sentry error tracking and OpenTelemetry. Each event includes an event timestamp and a random UUID stored locally as distinct_id in .blaxel/telemetry.json under your home directory. The CLI reuses this ID across local invocations. It does not derive the ID from an account, workspace, email address, hostname, or hardware identifier. The local file also records successfully reported CLI versions and the first-resource marker to reduce duplicate reporting. The common event properties are:
  • cli_version, when the running version matches the release-version allowlist. Version properties accept numeric releases and alpha, beta, or rc prereleases; arbitrary build text is omitted.
  • os: darwin, linux, windows, or unknown.
  • architecture: amd64, arm64, 386, arm, or unknown.
  • install_method: shell, powershell, homebrew, or unknown, inferred from the current installer invocation or executable location. It is not a complete history of how the CLI was installed.
  • environment: prod, dev, local, or unknown. This is the Blaxel environment the CLI is pointed at, from BL_ENV or the current workspace’s configuration, so development and production traffic can be told apart. It is not a workspace name or ID.
  • $process_person_profile: the boolean false, requesting no person-profile processing.
  • $geoip_disable: the boolean true, requesting no GeoIP enrichment.
Event-specific properties are limited to these values:
  • Setup status: success, failure, or cancelled. Login status: started, success, failure, or cancelled. Skipping or quitting the setup login, pressing Ctrl+C during browser login, or leaving the workspace picker counts as cancelled.
  • detected_agents: locally detected IDs from claude-code, codex, cursor, gemini-cli, github-copilot, opencode, amp, cline, windsurf, goose, kiro-cli, roo, continue, augment, junie, trae, qwen-code, openhands, pi, crush, devin, openclaw, vscode, and claude-desktop. No agent prompts or MCP protocol output are captured.
  • components: selected setup categories from skills, mcp, docs, login, and tracking. These describe the selected work, not a per-component success report.
  • failure_category: usage, validation, authentication, not_found, conflict, operational, internal, or panic. If multiple setup tasks fail, only one category is reported. Raw error text is excluded.
  • resource_category: Agent, Function, Sandbox, Job, Model, Volume, or Drive.
Usage event payloads exclude account and workspace IDs or names, emails, hostnames, paths, command arguments, environment-variable values, credentials, file contents, and raw errors. No IP address is added to the event body. The analytics receiver still receives a network connection; the GeoIP flag does not by itself establish how that receiver handles or retains the source IP address. The existing tracking preference in the local configuration described under Error tracking below controls both CLI usage reporting and local SDK/CLI error tracking. Setup labels its toggle Usage and error reports and keeps an existing saved choice. New setup plans retain the existing selected-by-default choice; the separate first-use consent prompt retains its default of no. Without a saved choice, the SDK’s existing tracking default remains off. Usage capture is disabled regardless of a saved tracking: true when:
  • DO_NOT_TRACK has any nonempty value, including 0, false, or whitespace.
  • BL_INSTALL_TRACKING is false (case-insensitive, ignoring surrounding whitespace).
  • Any of CI, GITHUB_ACTIONS, GITLAB_CI, CIRCLECI, TRAVIS, JENKINS_URL, BUILDKITE, or TEAMCITY_VERSION has a nonempty value.
You can also turn off the setup toggle or set tracking: false in the local configuration. BL_INSTALL_TRACKING=false disables usage capture directly and selects the setup toggle off. It does not independently override Sentry or SDK error tracking.
Usage reporting intentionally treats DO_NOT_TRACK=0 and DO_NOT_TRACK=false as opt-outs. Error tracking retains the existing SDK semantics described below, where those values enable error tracking. The CLI usage opt-outs do not change OpenTelemetry or sandbox runtime reporting.

Measurement limits

Usage delivery is best effort: requests have a one-second timeout, process-exit flushing waits at most one second, and the CLI drops excess events instead of queueing them when eight requests are already in flight. Setup and login attempts are not stored for offline replay. Failed version or first-resource delivery leaves the local marker eligible for a later invocation or creation. The first-resource event measures a successful create observed by an opted-in CLI installation. It does not confirm that a resource is ready or that a deployment finished, cover resources created through the Console or SDKs, or establish the first resource for an account. The anonymous local ID is not joined to identified server events. Resetting the local state, separate homes, concurrent CLI processes, opt-outs, and delivery failures can make this funnel incomplete or produce duplicates.

Error tracking

When enabled, the SDKs and CLI capture errors and exceptions that originate from the SDK/CLI itself - not from application code. Each SDK/CLI has a lightweight, custom Sentry client that collects and tracks the following error-related metadata:
  • Error type and message
  • Stack trace
  • Environment
  • Release/version
  • Workspace
  • Commit hash
  • OS/runtime context
  • Breadcrumbs
  • Runtime-specific context (e.g. goroutine info in Go)
No request data, API keys, file contents, IP addresses or other user or application data is collected.

Opt in

Error tracking is controlled by a combination of the DO_NOT_TRACK environment variable and the tracking parameter, read from the following locations (in priority order):
  1. DO_NOT_TRACK environment variable
  2. tracking: field in ~/.blaxel/config.yaml
  3. Pre-set default value
    • false starting from SDK v0.2.46 (Python), v0.2.76 (TypeScript), and v0.16.1 (Go)
    • true in all earlier versions
The Blaxel CLI prompts the user for tracking consent on first interactive use and during installation. The response is recorded in ~/.blaxel/config.yaml and affects error tracking in the SDKs and the CLI locally.
Consenting when prompted sets tracking: true in ~/.blaxel/config.yaml, which is read by both the CLI and SDKs and results in error tracking becoming enabled for local sessions.However, when deploying on Blaxel, the platform automatically injects DO_NOT_TRACK=1, which disables error tracking regardless of the value set in ~/.blaxel/config.yaml. You can override this by explicitly setting DO_NOT_TRACK=0 in your environment configuration (see below). Similarly, in CI environments or in remote environments where the Blaxel CLI is not used, the tracking: field is never set to true and error tracking is therefore disabled by default.

DO_NOT_TRACK environment variable

The DO_NOT_TRACK environment variable follows the Console Do Not Track convention. To explicitly enable tracking, use the command below in your shell environment:

Blaxel configuration file

You can also disable tracking by adding the following parameter to your ~/.blaxel/config.yaml global configuration file:
Setting BL_ENABLE_OPENTELEMETRY=0 has no effect on error tracking.

OpenTelemetry tracing and logging

When you deploy from the Blaxel Console, Blaxel CLI or by using the Blaxel SDK to wrap your code for deployment, Blaxel automatically instruments your requests with logging and tracing. The resulting logs and traces are provided to users for real-time monitoring and debugging of their workloads. The data collected consists of:
  • Metrics: Aggregated data about workload executions
  • Logs: Timestamped logs for workloads
  • Traces: Data on inputs, outputs and execution steps
Blaxel only collects and saves traces for a sampled 10% of all your executions. Read more about observability.

Opt in locally

This feature is controlled by the BL_ENABLE_OPENTELEMETRY environment variable. This environment variable defaults to false locally and to true in deployed environments. To explicitly enable it locally, use the command below in your shell environment:
Setting DO_NOT_TRACK=1 has no effect on OpenTelemetry.

Sandbox runtime error reporting

The Blaxel sandbox runtime (sandbox-api) reports internal errors to Sentry. The data collected is limited to:
  • Error type and message
  • Stack trace
  • Environment
  • Release/version
  • Runtime context (e.g. goroutine info)
Request context and user data are unconditionally stripped server-side before any data leaves the process. No request payloads, API keys, user identifiers, or IP addresses are transmitted. When telemetry is active, sandbox-api logs an explicit notice at startup.

Opt out

Sandbox runtime telemetry is controlled independently from the SDK/CLI DO_NOT_TRACK variable. Use either of the following in your sandbox image configuration:
TELEMETRY_ENABLED and --disable-telemetry only affect sandbox runtime error reporting. They have no effect on SDK/CLI error tracking (controlled by DO_NOT_TRACK) or OpenTelemetry tracing (controlled by BL_ENABLE_OPENTELEMETRY).
Last modified on October 20, 2026