Product Guides
Issues
Use Issues for regressions Vight can name with enough confidence to guide triage.
Overview
Use Issues when Vight has enough evidence to name a regression. Issues are investigation leads, not generic notifications. They should guide ownership, release review, and proof gathering.
Use this page after you know the approximate symptom and need to decide which evidence should come next. Keep the service, environment, and time range consistent as you move from summary pages to request-level detail.
How to read this page
Treat Issues as investigation leads backed by product evidence, not generic notifications. Use the issue status to separate new, active, and resolved work. Open related services, traces, logs, errors, and releases before closing the loop.
- Regression window
- The time window tells you when behavior changed and which data to compare.
- Affected owner
- Service, route, version, and environment suggest who should inspect the issue.
- Supporting evidence
- Related traces, logs, errors, and releases determine whether the issue is actionable.
Investigation workflow
Use this sequence when you need to move from a broad symptom to evidence you can share with another teammate.
- 1
Open a new issue and confirm which service and route changed.
- 2
Compare the issue timing with releases and recent versions.
- 3
Open traces and logs before assigning ownership or closing the issue.
Interpretation note
Do not treat an issue as an alert replacement. Alerts are configured response rules. Do not close an issue because one request looks healthy. Do not assign a release regression without checking timing and request evidence.