Format
Structured product events, not an unbounded log dumpGive support the product events that matter.
Send a bounded event name, level, message, and properties through the BTX SDK. Support sees the recent sequence beside the customer instead of searching a raw log stream.
BTX device logs are structured customer telemetry, not a copy of every engineering log. On iOS, BTX.log accepts an event immediately and queues delivery; Flutter exposes the equivalent Btx.log API. Each event stays connected to the identified customer and can carry the product properties needed for support.
Identity
Connected to the authorized customer and deviceDelivery
Queued without blocking the customer appSend the events the support team can act on.
A larger log stream is not automatically more useful. Product teams should choose events that describe state changes, failure codes, relevant configuration, and recovery milestones.
BTX keeps those events connected to the customer and device instead of asking support to search a separate observability system with an incomplete identifier.
State changes
Connection, setup, permission, charging, activation, and firmware transitions.
Failure evidence
Stable product error codes with enough context to identify the affected workflow.
Release context
App version, firmware version, model, and configuration that shape the behavior.
Recovery events
Positive evidence that the device returned to the expected state.
Collect deliberately, not indiscriminately.
The host product chooses which structured fields to send. Sensitive values should be excluded or transformed before they leave the app, and only context needed for an authorized support purpose should be attached.
Customer identity, telemetry, and support access should follow the same workspace and application boundaries rather than becoming a separate shadow dataset.
Keep engineering observability and customer support connected.
BTX does not need to replace every engineering logging system. It gives the support team the customer-facing slice of product evidence and a shared identity for deeper investigation when engineering needs it.
A practical support-event schema
| Field | Purpose | Example |
|---|---|---|
| Event name | Stable description of what occurred | device_reconnect_failed |
| Occurred at | UTC event ordering | 2026-09-15T17:43:12Z |
| Device context | Affected product identity | Model, device ID, firmware |
| App context | Customer-side software state | Platform and app version |
| Properties | Bounded diagnostic detail | Transport and product error code |
Use product-defined fields and exclude secrets, raw credentials, and unnecessary personal data.
Frequently asked
Are device logs the same as full engineering logs?
Not necessarily. Customer support usually needs a structured, privacy-safe set of product events. Engineering can retain deeper observability in its existing systems.
Can logs be attached before a customer opens support?
Yes. Authorized product telemetry can provide the recent sequence that explains what happened before the customer wrote in.
Does telemetry logging slow down the app?
The BTX SDK documentation describes queued telemetry delivery that does not block the app while each event is sent.