Self-filing issues: how triage went from asking the user to copy and paste

How we used to chase bugs

Debugging used to start with whatever the user could tell us. A message comes in — "the invoice page doesn't work" — and the PM goes back with the usual questions: which button did you click, what were you trying to do, can you send a screenshot? Then the real problem shows up: everyone involved has different experience and a different mental model, so even after several rounds, what the user meant and what we understood could still be two different things.

With better tooling, that entire report-and-triage loop can be automated — root causes get located fast, and a first draft of the fix often comes with them.

Record the error the moment it happens

If your logging is any good, the system already writes down everything that matters: which API, what parameters, which layer failed, at what time, triggered by whom.

But logs used to be passive. The error was recorded, sure — and then it sat there. Someone still had to wait for the user to report it, for a PM or SA to do a first pass, and only then would an engineer go in and dig out the raw entries, where noise and signal live side by side and experience is the only filter that tells you which lines matter.

That's the gap: logging and tracking were two separate worlds. Logs stayed logs, issues stayed issues, and a human carried things between them — see the error, copy the content, open a ticket, describe it, assign it.

So I closed the gap at the middleware layer. Every request and every SQL command flows into Seq as structured events, sensitive fields masked before they land, legacy noise filtered out so only observation points and errors remain. And each error is classified on arrival: business-rule rejection or genuine system bug.

Then the last step: when production hits an unexpected error, the system opens the issue itself. No one has to report it. No one has to describe it. The ticket just appears.

Auto-filed production issues in the tracker, classified and labelled on arrival

What a self-filed issue contains

Error summary — environment, classification, route, HTTP status, error code, operator, RequestId, timestamp.
Request parameters — the actual payload, sensitive fields already redacted.
Diagnostic instructions written for an AI — a block you can copy as-is: trace from this route's controller down through the service layer to the database, collect the relevant code along the way, and compare it against the exception stack and error code to find the root cause. With one rule attached: every conclusion needs verification — a failing test or an actual trace. Anything without verification gets filed as an unverified suspicion, never as a finding.

A self-filed issue: error summary, redacted payload, and a copy-paste diagnostic block

What changed after it shipped

So far the loop has correctly fixed 65+ production issues, most of them already closed — and each closure now carries a full write-up of how it was fixed, something human memory used to skip or leave half-written.

The old flow — report, clarify, investigate, open an issue — became: issue lands in the repo, paste it to an AI, a human judges the result, fix and close.

Root-cause analysis and fix verification, documented directly on the issue

And because business-rule rejections carry their own label (obs:business-fail), the tracker stays clean. Real bugs don't drown in false alarms.

Where humans still come in

The pipeline, as it stands:

Only catches what throws. Logic that computes the wrong number but finishes cleanly leaves no trace; people or tests still have to find those.
Sees actions, not intent. The log knows what the user did, not what they were trying to achieve. UX confusion never shows up in an error log.
Doesn't set priorities. Issues file themselves, but someone still has to decide what gets fixed first.