Skip to main content
Live telemetry gives you progressive visibility into a phone session. It uses the same span-and-log frame envelope that you can retrieve later, but live delivery and retained storage are separate best-effort paths. Use the live stream to monitor work as it happens. Use retained telemetry to reconcile the available record after the session ends or after you detect a live gap.

Follow an active session

  1. Open Sessions.
  2. Select an active session.
  3. Click Observability.
Timeline pairs span starts and ends as work progresses. Console displays output and error logs. Select a timeline row to inspect its currently available details.When the session ends, the Dashboard replaces the live view of the trace with retained history.

Protect the capability URL

The telemetry URL contains a bearer credential in its query string.
  • Treat the entire URL as a secret.
  • Do not put it in application logs, analytics, screenshots, or referrer data.
  • Share it only with the process that reads this session’s telemetry.
  • Do not send device commands over this connection. The stream is read-only.
  • Discard the URL when you no longer need it.
The capability is scoped to one session and can attach only while that session is active. There is no refresh message inside the WebSocket. You can reconnect with the same URL while it remains valid, or mint a new URL while the session is still active. Switch to retained retrieval after the session ends.

Parse frames and transport messages

Current first-party producers normally send one frame object in each WebSocket text message. Build a raw reader that accepts either one frame object or an array of frame objects. Array tolerance follows the transport contract; it does not mean the server currently batches arrays. Frames use a kind discriminator such as span or log. Cursor and resync objects are transport messages, not telemetry frames:
Accept new fields and unfamiliar span_type or log_type values. Support for an unfamiliar top-level kind depends on the client and version. See the frame compatibility guidance before choosing a generated or handwritten decoder.

Resume from a cursor

To receive checkpoints, preserve every query parameter in the returned URL and set resume=1. After you receive a checkpoint, store its cursor value as an opaque string. On reconnect, add or replace cursor with that exact value:
The cursor requests entries strictly after the checkpoint. Do not parse its format or use it as a timestamp. If the cursor is outside the available live replay window, the stream sends RESYNC_REQUIRED and continues near the current stream tail. It does not reconstruct the missing history for you. Retrieve the retained record before treating your local view as reconciled.

Set delivery expectations

  • Late attach and reconnect can replay a bounded recent window. No fixed public replay duration or entry count is guaranteed.
  • Reconnect can redeliver frames. Tolerate duplicates.
  • Live delivery is best-effort. Replay tolerance does not guarantee that every produced frame reaches every subscriber.
  • A live frame does not prove that an identical record was retained.
  • Do not assume every started span receives a live end frame.
  • The live and retained paths are not exactly-once services.
For retry classification, gap recovery, and terminal outcomes, follow Reliability and troubleshooting.

Next steps

Retrieve telemetry

Page through retained history or refill after a live gap.

Frame reference

Parse spans, logs, attributes, and additive values.

Reliability and troubleshooting

Handle interruption, duplication, gaps, and expired history.

Data controls

Protect sensitive telemetry and understand retention.