23Build

This deployment, exactly.

Branchmain
Messagefeat(status): redesign the Web Vitals tiles to match the uptime panel The old tiles were a mono code plus one sentence ("Collecting since Jul 10, 2026: 13 of 20 samples so far.") - no hierarchy, no geometry, nothing enterprise about them. Rebuilt with the same surface language as the uptime panel (elevated card, hairline border, faint sheen, token-derived gradients), one anatomy across all three honest states: - Head: metric code + state pill (Good / Needs improvement / Poor via the store's rating, or an accent "Collecting" pill with a gentle pulse), full metric name on its own line beneath. - Ready: large tabular-numeral p75 + unit, then a segmented threshold meter - fixed good/needs-improvement/poor bands with the p75 marker placed piecewise-linearly, drawn from the same THRESHOLDS the rating logic uses (now exported from lib/vitals-store.ts), boundary values ticked beneath (2.5s/4s, 200ms/500ms, 0.1/0.25) - and a samples substat. - Bootstrapping: a fixed 20-slot progress track (MIN_SAMPLES_
Environmentproduction

No deploy-timestamp field: Vercel doesn't inject one, and a cold-start clock read isn't reliably the real deploy time on a warm instance; that would be a claim without a mechanism behind it, so it's left out.

24Performance

Real visits, not lab runs.

Core Web Vitals collected from actual visitor page loads (only when analytics consent is granted), aggregated into a rolling 30-day p75. Below 20 samples, a percentile is noise, not a signal. Those metrics show a collecting state instead of a number.

LCP
Good
Largest Contentful Paint
2296ms
48 samples · since Jul 10, 2026
INP
Good
Interaction to Next Paint
48ms
33 samples · since Jul 10, 2026
CLS
Collecting
Cumulative Layout Shift
0 of 20 samples

A p75 below 20 samples is noise, not a signal.

25Uptime

Checked independently.

100.00%
30-day window · 112 checks
All recent checks passing
passfailawaiting sample

100.00% uptime over the last 112 checks · checks since Jul 10, 2026. Checked every 10 minutes by an independent GitHub Actions workflow, not self-reported by this app, since a server can't honestly measure its own downtime while it's down.

GitHub Actions cron is best-effort with documented delay under load, and disables entirely after 60 days of repository inactivity. This is not a dedicated-SLA monitor.