{"version":"2.1.277","anchor":"new-wall-clock-latency-telemetry-fields-for-turn-timing-over","canonical_anchor":"new-wall-clock-latency-telemetry-fields-for-turn-timing-over","heading":"New wall-clock timing fields added to turn telemetry","tier":"internal","area":"Telemetry","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/new-wall-clock-latency-telemetry-fields-for-turn-timing-over","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### New wall-clock timing fields added to turn telemetry\n\nTurn results now include detailed timing fields breaking down transit, queueing, and processing latency\n\n**What**\n\nThe telemetry sent with turn results gained several new optional timing fields to break latency down into stages:\n\n- `first_stream_post_queue_wait_ms` and `first_stream_post_queued_behind`, showing queueing latency and what it was queued behind.\n\n- `frame_received_wall_ms` and `frame_enqueued_wall_ms`, wall-clock timestamps for when a frame arrived and was queued.\n\n- `turn_started_wall_ms`, marking when the turn started.\n\n- `first_text_post_ms` and `first_text_post_wall_ms`, marking the first text output.\n\nThese fields are populated for sessions that read input from an SSE stream via `--sdk-url`, including headless\/hearth-relay turns.\n\n**Why**\n\nBreaking turn latency into transit, queueing, and processing stages makes it possible to diagnose where time is actually going in a slow turn, rather than only seeing total latency.\n\n- Area: Telemetry\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}