One signal, every millisecond

A person types a question into chat and presses enter. Somewhere between that key and the first word of the answer, a few seconds pass. Today we can say how many. We cannot say where they went.

The question crosses the person's browser, a Cloudflare city, the one.ie worker, the channels worker, a model behind AI Gateway, and back the same way. Each of those places keeps its own clock and its own notes. The one.ie worker writes a Server-Timing header. Channels logs a [chat-timing] line nobody keeps. A D1 table counts latency per receiver per day. None of them share a name for the signal, so nothing joins them up.

Tony asked for the join: "we want to trace a signal as it goes through our platform every ms until a user or agents receive a response back."

So the first door mints one id and hands it to the next door in a header. Every worker that touches the signal writes one short record, a span: which hop, when it started, how long it took, how it ended. The spans go to Analytics Engine, which takes a write for almost nothing and does not spend the D1 reads that ran out on 2026-09-25. Reading them back is one query by the id.

The hard part is the clock. On Workers, time does not move while the code is only computing. It moves when the code waits on the network. So a span can only be trusted at its edges — a request arriving, the first byte going out, the last byte leaving — and a number made by subtracting one worker's clock from another's is marked as mixed.

The turn is small and it changes what the number means. A chat turn's first byte was read at 3.1–7.4 seconds on 2026-08-19 (text/speed-results.md; not re-measured for this story). Traced, a turn like that turns out to be some milliseconds of ours, a gap on the wire, and the model's time to its first token. Those need opposite fixes, and until now they looked the same.

What the team learns from the first real trace is not written yet.