Release Health

1// Injected by the build. Same value as the asset content hash, so telemetry,
2// source maps and deploy markers all name the identical artefact.
3declare const __RELEASE__: string
4 
5export const RELEASE = __RELEASE__
6 
7// Attached at the single point every signal passes through — not at each
8// call site, where one surface will eventually be missed.
9export function envelope<T extends object>(signal: T) {
10  return {
11    ...signal,
12    release: RELEASE,
13    // occurredAt, not receivedAt: a beacon from a session that spans a deploy
14    // can arrive long after the release it belongs to stopped being current.
15    occurredAt: Date.now(),
16    sessionStartedOnRelease: SESSION_START_RELEASE,
17  }
18}
19 
20// The same value goes to the source-map upload and the deploy marker:
21//   npx upload-sourcemaps --release "$RELEASE" ./dist
22//   curl -X POST /deploys -d "{\"release\":\"$RELEASE\"}"

sessionStartedOnRelease is the field people leave out. A session that begins on one release and continues past a deploy is not cleanly a member of either cohort, and recording both lets the analysis exclude it rather than silently miscount it.

• Deploy completes; assets swap — Server-side this is the event. Client-side almost nothing has happened yet.
• Release N-1 still dominant — Every metric measured in this stretch is mostly a measurement of the previous release.
• Fast reloaders adopt N — Not a random sample: heavy users, fast connections, people who navigate often.
• Bulk adoption — Only here does the new cohort get large enough for its rates to mean much.
• Long tail on N-1 and older — Open tabs, cached service workers, infrequent visitors. Old releases keep reporting.
• Regression detected in cohort N — Detected by comparing N's own sessions against N-1's, not by a line moving on a clock.
• Clients still running N — The rollback is a new deploy with its own adoption curve. The bad release does not disappear; it decays.

The last row is the one that surprises people. Rolling back changes what new loads receive; it does nothing for a client that already has the bundle.

errors/min, hour before deploy vs hour after:

  before:  steady
  after:   up sharply

=> "the deploy broke it, roll back"

unexamined: what fraction of that hour was even
running the new build; what fraction of the rise
is the daily traffic peak; whether it is one route,
one browser, or everything.

crash-free sessions, per release, over each release's own sessions:

  release       sessions   crash-free   adoption
  2026.08.2     large      baseline     declining
  2026.08.3     growing    baseline     rising

  segmented — 2026.08.3 only:
    desktop            baseline
    mobile, engine A   baseline
    mobile, engine B   clearly worse   <- here

=> not a rollback: one engine, one route.
   Ship a targeted fix; leave the release up.

The cohort view computes each rate over the sessions that actually ran that build, so the comparison is unaffected by how fast adoption happened or by what the traffic mix did in the meantime. It also produced a better decision than a rollback — a targeted fix — which the aggregate view had no way to reach because it never separated the populations.