Metrics & Impact
// Production Quality & Observability
Turning production signals into test priorities
How error rates, logs, latency, and incidents should feed test prioritization and release decisions — shown on a live app anyone can inspect.
Demo on a personal project. My production-quality work at Mastercard, LiveSwitch, and Triomics is on the Experience page; this page shows the same thinking applied to code that's public.
The loop
- A production error or customer report comes in.
- Reproduce it with a test that fails for the right reason, before the fix.
- Fix it, and keep that test in regression so the same defect can't escape twice.
- Workflows with rising error rates or latency get more test depth, and open errors on critical paths count against release readiness.
What's wired today in Food Recommendations
| Signal | How | Status |
|---|---|---|
| Server and edge errors | Sentry via instrumentation.ts, with captureRequestError on every request error | Wired |
| Browser errors and render crashes | Client-side Sentry, plus error.tsx and global-error.tsx boundaries | Wired |
| Readable stack traces | Source-map upload, verified against a real production error | Wired |
| Performance traces | Sentry tracing at a 100% sample rate | Wired — fine at hobby traffic, would be sampled down at scale |
| Abuse and traffic spikes | Upstash Redis sliding-window rate limits on 5 routes, returning 429 | Wired, not yet covered by a test |
| Structured logs and request IDs | — | Not yet |
| Release tagging | — | Not yet |
How those signals set test priority
| Signal | Testing and release decision |
|---|---|
| New error on the submit or like route | Reproduce it with a Playwright test against that route before fixing; the test joins regression |
| Error rate up on a critical workflow after a deploy | Treat it as a release blocker and widen test depth around that workflow |
| Search latency creeping up | Add a performance check on the trigram search path before the next release |
| Spike in 429 responses on one route | Check the limit is right, and add a test that asserts the 429 path |
Honest gaps, and what I'd add next
- No test asserts the rate limiter's 429 path today — the suite clears its own keys to stay out of the limiter's way. That's the first test I'd add.
- No structured logging or request IDs, so a user report can't yet be tied to a specific trace.
- No release tagging in Sentry, so an error spike can't be attributed to the deploy that caused it.
- Two security fixes — image content-type spoofing and unbounded field lengths — shipped without regression tests. Those are the next tests I'd write, and exactly the gap the loop above exists to close.