reaches its preview in 6.1s is the direction's own number, and it landed with #109. A person who reads it and wants it smaller has nowhere to look: the line says how long, never where the time went.
previewLatency (src/core/runs.ts:633) takes one interval — created_at to serving_at, the push to the moment it answered — and previewLatencyWords (src/web/studio/app.ts:83) prints its median. The run table already holds the seam inside it: started_at is stamped when the deploy actually begins (runs.ts:162), so every served deploy carries two segments, not one — waiting to be picked up (created_at → started_at) and coming up (started_at → serving_at). Six seconds of queue and six seconds of boot are two different problems with two different fixes, and today they read the same.
Acceptance
[ ] previewLatency returns the median of both segments beside the total it already returns, from the same one query over the same bounded, newest-first walk — no second query, no scan.
[ ] The app page's line says the split in the studio's own plain words, on one line, without pushing the panel wider: the total stays the headline and the two parts read as its explanation.
[ ] A deploy missing started_at is left out of the split the way one missing serving_at is left out of the total — never counted as a zero — and the count the line quotes still says what it is drawn from.
[ ] Below PREVIEW_LATENCY_MIN served deploys the line says so, exactly as it does today.
[ ] Tests: deploys seeded with known created_at/started_at/serving_at produce the expected two medians; one with a null started_at is excluded from the split but still counted in the total. They fail on today's code.
[ ] bun test green, and the app page's first byte does not move.
Files I expect to change
src/core/runs.ts (previewLatency and its interface), src/web/studio/app.ts (previewLatencyWords), test/studio.test.ts.
Risks
Three medians taken independently do not add up to each other — the median total is not the median queue plus the median boot. Either say each is its own median, or take the split from the same rows as the total; whichever you choose, do not print arithmetic that a reader can check and find wrong.
This is the shallow seam, the one the schema already has. A deeper breakdown — checkout, install, boot — needs marks the deploy does not write yet, and is a separate issue if this one shows the time is going somewhere it cannot see.
reaches its preview in 6.1sis the direction's own number, and it landed with #109. A person who reads it and wants it smaller has nowhere to look: the line says how long, never where the time went.previewLatency(src/core/runs.ts:633) takes one interval —created_attoserving_at, the push to the moment it answered — andpreviewLatencyWords(src/web/studio/app.ts:83) prints its median. Theruntable already holds the seam inside it:started_atis stamped when the deploy actually begins (runs.ts:162), so every served deploy carries two segments, not one — waiting to be picked up (created_at→started_at) and coming up (started_at→serving_at). Six seconds of queue and six seconds of boot are two different problems with two different fixes, and today they read the same.Acceptance
previewLatencyreturns the median of both segments beside the total it already returns, from the same one query over the same bounded, newest-first walk — no second query, no scan.started_atis left out of the split the way one missingserving_atis left out of the total — never counted as a zero — and the count the line quotes still says what it is drawn from.PREVIEW_LATENCY_MINserved deploys the line says so, exactly as it does today.created_at/started_at/serving_atproduce the expected two medians; one with a nullstarted_atis excluded from the split but still counted in the total. They fail on today's code.bun testgreen, and the app page's first byte does not move.Files I expect to change
src/core/runs.ts(previewLatencyand its interface),src/web/studio/app.ts(previewLatencyWords),test/studio.test.ts.Risks
Three medians taken independently do not add up to each other — the median total is not the median queue plus the median boot. Either say each is its own median, or take the split from the same rows as the total; whichever you choose, do not print arithmetic that a reader can check and find wrong.
This is the shallow seam, the one the schema already has. A deeper breakdown — checkout, install, boot — needs marks the deploy does not write yet, and is a separate issue if this one shows the time is going somewhere it cannot see.
Suggested: Mason.