Understand problems in production
Use errors, performance data, and support reports to find out where people get stuck.
Why this matters
Observability — ways to notice and diagnose failures after launch — answers one question: when someone cannot finish a task, what happened? The server responding is only one signal. The interface may still fail to render, save, or confirm the result.
What to understand
Take an invitation flow. You need to tell apart: form submitted, invitation saved, delivery queued, delivery failed, and recipient accepted. Those are different outcomes with different owners. Pick signals that support a decision. Do not log every click because a tool makes it easy.
Watch for
- Alerts with no owner and no first steps — noise that trains everyone to ignore them.
- Raw form entries, passwords, tokens, or unneeded personal details in logs and analytics.
- Browser console output treated as private storage.
- A metric just outside the "good" threshold read as automatically "poor."
- A traffic shift mistaken for a code regression.
Strong default
Record the release, environment, route or operation, safe error code, and correlation ID — a shared identifier that ties related log entries together. Redact at the source and set retention and access. Tie each alert to user consequence, with a responsible owner and first steps pointing at the affected release or step and a runbook.
When this doesn't apply
More instrumentation is not better instrumentation. Logging every click because the tool makes it easy buries the signals that support a decision; timing or state belongs in an event only when it helps diagnose the problem. If no one can act on an alert, fix the signal or ownership rather than normalizing the noise.
In practice
| Signal | Helps answer |
|---|---|
| Error event | Which step failed, in what version and environment? |
| Metric | How often or how slowly does this happen? |
| Trace or correlated request | Which outside service contributed to the failure? |
| Product event | Did the task reach its defined outcome? |
| Support report | What consequence or confusion did the person feel? |
Track relevant load, interaction, and stability signals across real devices. Keep the current Web Vitals definitions and your product's task budgets separate. Use lab measurements — controlled, repeatable tests — to diagnose a repeatable problem, and field data — measurements from real use — to see how widespread it is. Compare matching populations and releases.
First limit harm: disable the affected path, undo a compatible release (saved data stays saved), or explain what is unavailable. Then establish scope, keep relevant evidence, and fix the cause. Sort out uncertain writes before assuming retries are safe. Afterward, record what happened, why checks missed it, and the smallest useful change to tests, defaults, or the runbook.
Verify
Ask your agent to run $readiness to check operational gaps. Every alert should name who responds, what user consequence triggers it, and where the first steps live.
Related skills
Use $readiness for the operational check. Continue with client delivery for assigning ownership, so the next maintainer can find both the code and evidence of how it behaves.
Last updated on