A useful observability review in 2026 starts with a human task: can the engineer on call explain why a business operation failed? The presence of traces, metrics and logs is necessary evidence of instrumentation, but it is not evidence of an effective investigation.
Design a controlled failure
In a non-production environment, make one dependency slow or unavailable. Choose a workflow with an asynchronous step, such as document generation, so the exercise crosses both request and worker boundaries.
Ask a colleague who did not build the feature to investigate. Provide the normal alert and runbook. Observe which questions they can answer: when did failures begin, which operations were affected, and did retries eventually complete?
Record gaps as product work
A missing correlation identifier is a concrete defect. So is an alert that cannot distinguish a failed customer operation from an expected validation error. Give each gap an owner and repeat the same scenario after it is fixed.
Check data exposure during the exercise. Diagnostic usefulness should not depend on collecting tokens, full request bodies or personal information by default. Review retention and access alongside instrumentation.
The outcome should be a shorter, more reliable route from alert to explanation. A dashboard can support that route, but it should not become the acceptance criterion itself.
Reference
OpenTelemetry’s .NET documentation provides the signal and instrumentation foundation for this proposed exercise.