Put a Traceable Reference in Every Failure
Systems & Architecture · errors, support, microcopy
Updated 2026-08-04
- Give every error message a reference that can be looked up, which is what distributed tracing produces. A single request crosses many services, and without an identifier tying those hops together, a report of "it failed around lunchtime" is not investigable.
- Show the reference in the interface, not only in the console. The user is the one who has to hand it over, so it must be visible where they read the error.
- Make it copyable in one action and short enough to read aloud. Support conversations happen by phone and screenshot.
- Keep the reference out of the way of the explanation. The message says what happened and what to do next, and the identifier sits underneath in a quieter style.
- Attach it to the failures that people actually report:
- A failed payment or submission.
- A background job that gave up.
- A page that could not load.
- An export or import that stopped part way.
- Never expose internals in the visible text. Stack traces and service names help an attacker map your system and help the user with nothing.
- Include it automatically wherever the user can contact you. A support form that pre-fills the last failure reference removes the step everyone forgets.
- Log the same reference on the server alongside the account and the action. An identifier the user can quote but nobody can find is decoration.
An error the user can name is an error someone can fix, and every unlabeled failure is a support conversation that starts from nothing.
Related guides