Public: anyone can read this; the crew can change it.
The cloud settings page's Server-Timing names its phases: session, each read, render #3472
Check · Review · Land · Live done — Landed and live in production.
`GET /settings/cloud` now answers with a Server-Timing header naming `session`, `reads`, `uses`, `accounts` and `render`, the same way the milestones page does.
shipped production is serving it deploy 119f4d2
GET /settings/cloud now answers with a Server-Timing header naming session, reads, uses, accounts and render, the same way the milestones page does.
I could not run the type check. bun x tsc --noEmit and bun install both failed in this sandbox with "bun is unable to write files to tempdir", so the forge's check will be the first type check. The new test and the existing test/cloud.test.ts and test/cloud-gate.test.ts pass (21 tests).
- Change: the phases come from
notePhaseandtimePhaseinsrc/core/route_timing.ts, insrc/web/pages/cloud.ts.
- session is recorded first, before the admin check.
- reads wraps recentCloudReads.
- uses wraps usesByVendor, with the async variant of timePhase.
- accounts wraps listCloudAccounts.
- render times building the page.
- Account list moved:
listCloudAccountsused to be called insideaccountsCard. It is now called incloudPage, afterusesByVendorand before the page is built, so it runs in the same order as before.accountsCardtakes the list as an argument. - Unchanged: the page's body, status codes and caching.
- Test:
test/cloud-timing.test.tsrequests the page as an admin. It asserts each of the five names appears exactly once with a numeric duration, and no wall-clock time. It fails without the change because the header lacks those names. - Left out: the POST handlers and
/settings/cloud/auditare not timed.
To try it, sign in as an admin, open /settings/cloud, and read the Server-Timing response header.
🤖 Generated with Claude Code
Follows the pattern boards-view, forges and settings already use (notePhase/takeSessionTime/timePhase), no markup or design change, admin gate unchanged, and the test pins all five phase names once each with numeric durations. I could not reach the preview from my sandbox, so this is a source read only. Next: (1) time the POST handlers and /settings/cloud/audit the same way; (2) the test titles say #3444 while the pull is #3472, so align the reference.
GET /settings/cloudnow answers with a Server-Timing header namingsession,reads,uses,accountsandrender, the same way the milestones page does.I could not run the type check.
bun x tsc --noEmitandbun installboth failed in this sandbox with "bun is unable to write files to tempdir", so the forge's check will be the first type check. The new test and the existingtest/cloud.test.tsandtest/cloud-gate.test.tspass (21 tests).notePhaseandtimePhaseinsrc/core/route_timing.ts, insrc/web/pages/cloud.ts.-
sessionis recorded first, before the admin check. -readswrapsrecentCloudReads. -useswrapsusesByVendor, with the async variant oftimePhase. -accountswrapslistCloudAccounts. -rendertimes building the page.listCloudAccountsused to be called insideaccountsCard. It is now called incloudPage, afterusesByVendorand before the page is built, so it runs in the same order as before.accountsCardtakes the list as an argument.test/cloud-timing.test.tsrequests the page as an admin. It asserts each of the five names appears exactly once with a numeric duration, and no wall-clock time. It fails without the change because the header lacks those names./settings/cloud/auditare not timed.To try it, sign in as an admin, open
/settings/cloud, and read theServer-Timingresponse header.🤖 Generated with Claude Code
Closes #3444