Skip to main content
Telemetry provides progressive visibility into a session and a retained record for later retrieval. Both delivery paths are best effort. Build consumers that can tolerate duplicates, detect gaps, and reconcile with the available archive. Telemetry is not an exactly-once or complete audit ledger. Axilio does not publish a formal availability, completeness, replay, or durability SLA for this data.

​
Use the live and retained paths together

The live stream and retained archive are independent delivery paths:
  • a frame observed live is not proof that the same record was durably retained;
  • a retained span is not a byte-for-byte replay of its live start and end messages;
  • reconnect can replay frames you already processed; and
  • moving to the current live tail does not repair an earlier gap.
Use live Telemetry for progressive updates. Use GET /phones/sessions/{session_id}/frames to reconcile after a gap and after the session ends.

​
Resume without assuming exactly-once delivery

Opt in to cursor checkpoints with resume=1. Store each opaque CURSOR value only after you have processed every frame that came before it. On reconnect, preserve the returned URL and its existing parameters. Add or replace resume=1 and cursor=<opaque-value>. Never parse, construct, or depend on the cursor’s encoding.
The stream can redeliver frames around your last completed checkpoint. A consumer that needs exactly-once presentation must deduplicate them locally. Useful identities include:
  • (trace_id, span_id, phase) for a span;
  • stable session, span, timestamp, and body fields for a log; and
  • the complete normalized JSON for an unknown frame.
Python’s high-level live reader deduplicates replayed frames. Go can expose duplicates to your consumer.

​
Recover after a replay gap

The live replay window is bounded, but Axilio does not publish a guaranteed duration or entry count. If the stream sends:
or an SDK reports a gap:
  1. Retrieve every available retained page for the session.
  2. Deduplicate the retained frames against data you already processed.
  3. Rebuild the local trace from the reconciled record.
  4. If the session remains active, attach again and resume from a current checkpoint.
The Go stream exposes this state through Gapped(). CLI follow mode and the Python helper perform more reconciliation for you.

​
Reconnect with a bounded budget

Current first-party readers treat abrupt loss and observed WebSocket 1001, 1011, or 1013 closes as transient while a session is active. They use bounded exponential backoff with jitter. For a raw client:
  • retry transient connection loss with bounded backoff and the last completed cursor;
  • treat a normal 1000 close with reason session ended as terminal;
  • treat an attach 401 as a credential problem;
  • treat an attach 403 as terminal for that live URL; and
  • switch to retained retrieval when the session has ended.
These are observed current signals and first-party retry behavior, not an exhaustive versioned close-code contract. No public numeric size, throughput, viewer, buffer, or slow-consumer limit is currently published.
There is no in-band token refresh. You can reconnect with the same URL while it remains valid or mint another URL while the session remains active.

​
Account for interface differences

Do not describe unreleased SDK behavior as available. Check the package version used by your application before relying on a compatibility fix.

​
Troubleshoot common symptoms

For REST failures, parse the Problem Details response and follow Errors. A missing session and one outside your organization are intentionally indistinguishable. Do not interpret an authorization, validation, rate-limit, or internal failure as an empty trace.

​
Build a tolerant reader

A resilient custom reader should:
  1. accept one frame object or an array from the live transport, while recognizing that current producers normally send individual objects;
  2. ignore or preserve unknown fields within a known frame;
  3. treat new span_type and log_type values as additive;
  4. preserve an unknown nonempty string kind as raw JSON;
  5. reject malformed data without discarding other valid frames when possible;
  6. persist cursors only after processing preceding frames;
  7. tolerate replayed frames;
  8. paginate the retained archive to total; and
  9. avoid relying on a deterministic order among frames with equal timestamps.
See the Frame reference for the current span and log shapes.

​
Claims to avoid

Do not build or document an assumption that:
  • every produced frame reaches every live subscriber;
  • every event appears in retained history;
  • every live span receives an end frame;
  • replay is unlimited or time-guaranteed;
  • delivery is exactly once;
  • the Dashboard displays every retained frame or raw attribute;
  • all readers preserve an unknown top-level frame kind;
  • zero cost proves finalized free usage; or
  • the access-expiration timestamp is a physical-deletion deadline.

​
Next steps

Live telemetry

Connect, mint access, and follow an active session.

Retrieve telemetry

Refill from the retained record and page to completion.

Frame reference

Build a version-aware frame decoder.

Data controls

Control capture and protect sensitive Telemetry data.