Konfigurowanie alertów wydajności

Dashboards only help when someone is watching. Alerting proactively notifies the team when a metric crosses a limit, so regressions are caught even at 3am.

Alert on user-facing signals: Core Web Vitals (LCP, INP, CLS), error rate, and TTFB. These map to real experience better than raw server metrics alone.

Averages hide pain. Alert on p75 or p95 so you catch the slow tail of users that averages mask.

The simplest rule: fire when a metric exceeds a fixed value, for example p75 LCP over 2500ms for 5 minutes. Clear and predictable, but needs tuning per page.

Anomaly-based alerts learn normal patterns (including daily and weekly cycles) and fire on deviations. They adapt to traffic changes that would make static thresholds noisy.

Too many alerts get ignored. Add for-duration windows, sensible thresholds, and deduplication so transient blips do not page anyone.

Route alerts to the right channel: Slack for warnings, PagerDuty/on-call for critical. Define escalation so unacknowledged critical alerts climb the chain.

• Warning: trending bad, look soon.
• Critical: users impacted now, page on-call.

Map each metric breach to a severity so responses are proportional.

Annotate the timeline with deploy markers. When an alert fires right after a release, correlation makes the regression's cause obvious and rollback fast.

A good alert says what broke, how bad, since when, and links to the dashboard and runbook. The on-call engineer should know the next step at a glance.

• Alert on p75/p95 user-facing metrics.
• Use for-duration windows.
• Route by severity with escalation.
• Annotate deploys; link runbooks.

You learned to build effective performance alerting: alert on percentile user-facing metrics, choose static thresholds or anomaly detection, prevent fatigue with duration windows, route by severity with escalation, and correlate with deploys for fast triage.