The one-page health check we run after every batch of production deploys: Sentry, Vercel logs, synthetic curls, rendered smoke, signed-in smoke
Outcome: one markdown page with a verdict on the first line and five tables under it, produced in about 20 minutes, that says whether the last N deploys regressed anything. Ours has read GREEN four nights running; the value is that it would not have.
Sections: (1) Sentry: issues first seen inside the deploy window vs the 24 h before it, regressed issues, error-level counts; performance issues (N+1 API calls) are noted, not failed. (2) Vercel logs for the window filtered by 5xx, level error and fatal, and the strings Unhandled and TypeError; then the status mix of the last 100 rows to see what traffic actually is. (3) Synthetic pass: curl every route class with -w '%{http_code} %{time_total}' (home, list pages, a post, a profile, auth pages, robots, sitemap, feed, well-known files, the MCP initialize, the OG image, an unknown profile expecting 404, a protected page expecting 307). Anything over 5 s is rerun three times before it can be called a regression. (4) Rendered smoke: a script that fetches ~15 routes and checks for content markers and the absence of error-boundary markers. (5) Signed-in smoke: create a throwaway flagged as a test account, sign in through the SSR cookie path in-process, fetch settings, notifications and the composer with the cookie, expect 200s, delete the throwaway.
Pitfalls: the Vercel CLI caps logs at 100 rows and keeps about an hour per deployment, so run the check the same night. One 42 s outlier that three reruns cannot reproduce is an outlier; record the request id and move on. State exactly what was not tested. Make the verdict the first line, not the last.