Bringing error observability to a team that had none

claim 1.7dependent — cites claim 1 (Dynamox)

Gave a team that had no error monitoring a structured observability practice built from a shared reporter and request-time-tagged API interceptor plus dashboards and a triage workflow, turning production bugs from something reported by support into something the team can see and prioritize.

impactThe team went from no error monitoring to a structured observability practice, able to answer "which service or feature is failing most?" and to review open issues by priority.Production bugs became visible proactively instead of arriving only through support.Errors are attributable to feature and endpoint, thanks to request-time context tagging, and the setup is the base for post-deploy alerting.Qualitative: faster detection of production problems; no hard mean-time-to-detect number was captured.

Context

This is evidence that I spot and close gaps nobody assigned me, the same initiative that defined my earliest growth, now applied at team scale. Nobody asked for observability. I noticed we were the only team flying blind and made the case to fix it.

It also shows frontend systems thinking. The core of the solution is a shared, reusable instrumentation layer with a deliberate tagging design rather than a scattering of one-off error logs, plus the product sense to build dashboards around how the team actually triages.

Problem

The frontend was a shared codebase split across several teams' areas. Every other team's area had error monitoring; mine had none. The consequence was concrete: we learned about production bugs when a support ticket came in, not when the error happened. We had no way to see which parts of our area were failing, how often, or whether a release had made things worse, so triage was reactive and anecdotal.

Constraints

—Nobody owned the problem. It was a structural gap, not a ticket. Someone had to notice it and decide it was worth solving.

—Error attribution is the hard part. Catching errors is easy. Making each error carry enough context to say *which feature and which API call* produced it, while preserving the original failing route, is where the design lives.

—Instrumentation must be shared, not sprinkled. Ad-hoc error logging across dozens of routes would have produced noise. The value is in one consistent, reusable layer.

—Observability is only useful if it drives action. A dashboard nobody triages changes nothing, so the practice had to include a workflow.

Decision

I treated it as introducing a practice, not installing a tool.

—Diagnosed and made the case. I identified that our area was the only one without monitoring and proposed the initiative off my own diagnosis.

—Built a shared error reporter wired into the critical asynchronous flows, so errors are captured consistently instead of per-screen.

—Added a shared API interceptor that tags at request time. Each error carries context tags for team, feature, and the specific API service and endpoint. I captured them at the moment of the request so the tag reflects the route that actually failed, rather than whatever context existed when the error surfaced. I made it additive so it never overwrites existing tags.

—Built dashboards with thresholds, organized around how the team would actually use them, and mapped our area's routes to filters so errors could be sliced by feature.

—Defined the triage workflow, meaning how an error becomes a tracked ticket, so the monitoring turns into action, and set the base for post-deploy alerting.

Trade-offs

—Tagging at request time over tagging on the response/error. Capturing context when the request is made preserves the true failing endpoint for correct attribution; reading it later would sometimes mis-attribute the error. Accepted cost: a little more care in the interceptor.

—A shared instrumentation layer over per-screen error logging. One reusable reporter and interceptor is more design up front than scattered `catch` blocks, but scattered blocks would not have produced anything a team could act on.

—Additive tagging over overwriting. Never clobbering existing tags keeps the shared codebase's other context intact, at the cost of being disciplined about how tags are set.

—Dashboards by usage persona over a generic default. Building views around how the team triages takes more thought than an out-of-the-box dashboard, but the data then answers the questions people actually ask.

Impact

—The team went from no error monitoring to a structured observability practice, able to answer "which service or feature is failing most?" and to review open issues by priority.

—Production bugs became visible proactively instead of arriving only through support.

—Errors are attributable to feature and endpoint, thanks to request-time context tagging, and the setup is the base for post-deploy alerting.

—Qualitative: faster detection of production problems; no hard mean-time-to-detect number was captured.

Lessons Learned

Reusable engineering knowledge I carry forward from this:

—Nobody can prioritize a bug they can't see. Observability comes before reliability work, not after it.

—Attribute errors where the context is truthful. Tag at the point (request time) that preserves what actually failed, or your dashboards will mislead you.

—Instrument once, shared. A reusable reporter and interceptor beat scattered logging, because consistency is what turns error data into something you can act on.

—Observability needs a workflow. Without a triage path from error to ticket, the data never turns into a fix.

—Noticing an unassigned gap is part of the work. The diagnosis was worth as much as the code that followed it.

Evidence

—Proposed and led the initiative off my own diagnosis (our area was the only one without monitoring).

—Built a shared reporter and a request-time-tagging API interceptor, dashboards with thresholds, and an error-to-ticket triage workflow.

—Verified against the tracker (2026-05 to 2026-06): an epic I opened on 2026-05-25 and decomposed into five tasks: the shared reporter wired into the team's sagas (closed 2026-05-27), the team dashboard (2026-06-18), context tags on the critical pages (2026-06-22), automatic coverage via an HTTP-client interceptor, and user identification plus release tracking.

—Verified honestly as unfinished: two of the five tasks are still open. Release tracking never started, and the interceptor's coverage task remains in the backlog even though the interceptor itself shipped (a 27-comment pull request, merged 2026-06-08). The practice is real and in use; it is not complete.

—Source (private): Jira epic in the inspection domain, 2026-05 to 2026-06; consolidated career knowledge base.