Successful steps are not the whole result.
An HTTP 200, a completed queue job or a green service check describes one boundary. The customer’s task may cross several services and continue after that response.
- Export requested
- Export completed
- Download failed
An error tracker remains useful. It can only report the exceptions and other evidence you capture; a business result does not necessarily throw an exception.
Start with an observable success boundary.
Write down what the customer needs and which evidence can establish it. For paid access, this may include an authoritative entitlement check plus a successfully displayed feature. For exports, it may be a validated artifact and an authorised download response.
Keep identifiers consistent across the attempt. Separate authoritative server evidence from browser observations, and allow time for expected asynchronous work.
Silence is not enough.
A closed tab, blocked telemetry or an interrupted connection can explain a missing completion event. Keep that result unknown unless additional evidence supports a failure. Do not turn every abandoned flow into a bug report.
Use diagnostics and outcomes together.
Logs and traces explain execution. Error reports explain captured exceptions. Task monitoring helps connect configured evidence to the result the customer needed.
Compare Braith and Sentry, or follow a concrete payment-access example.