Regression alert thresholds reviewed quarterly
Why it matters
Stale alert thresholds turn your regression pipeline into noise. When baselines drift — new features, added dependencies, heavier pages — thresholds set at launch either fire constantly and train the team to ignore them, or sit so loose that real regressions slip past unseen. Both outcomes erode the signal that observability tooling is supposed to provide, and users pay the cost in LCP, TBT, and abandoned sessions the team never hears about.
Severity rationale
Info because stale thresholds degrade monitoring quality rather than directly breaking user-facing performance or availability.
Remediation
Put a recurring quarterly review on the calendar and record each pass in a tracked doc so the cadence survives team turnover. Capture the current baseline for each Core Web Vital, the threshold, and the date reviewed. Use a file like docs/performance-baselines.md:
## Q1 2026 Review (2026-03-15)
- LCP: baseline 1.8s, threshold 2.5s
- INP: baseline 180ms, threshold 200ms
- CLS: baseline 0.05, threshold 0.1
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Performance Deep Dive Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from performance-deep-dive·automated