Concepts & Reference
Alert Rule Examples
Start with practical alert patterns that catch customer impact without turning every normal fluctuation into a page.
Concept
Start with practical alert patterns that catch customer impact without turning every normal fluctuation into a page.
Good alerts should point to action: a service, route, SLO, owner, or investigation path.
Start with a small number of high-signal rules, then tune thresholds after real incidents.
Use Issues and Errors to decide which recurring symptoms deserve configured alerts.
Examples
- Critical route latency
- Alert when a user-critical route stays above its response target for a sustained window.
- Service error rate
- Alert when a service has enough traffic and its failure rate crosses the threshold your team treats as actionable.
- Release guardrail
- Alert when a newly deployed version clearly regresses latency, errors, or availability.
How Vight uses it
API latency: alert when a critical route stays above your response target for a sustained window. Error rate: alert when a service or route crosses a failure threshold with enough traffic to matter. Availability: alert when successful request rate drops below the level your users expect. Runtime pressure: alert when pressure signals align with latency or failures, not as isolated noise. Release guardrail: alert when a newly deployed version shows clear latency or error regression.
Usage guidance
Route each alert to an owner who can act on the target. Prefer sustained windows over instant spikes for user-facing response. Tune noisy rules after reviewing the service, trace, log, and issue evidence. Create alerts for recurring customer-impact patterns, not every interesting chart.