Setting Up Performance Alerts: Catching Site Crashes Instantly

Your site's performance is great — until it isn't. A new deployment, a third-party script update, or a traffic spike can tank performance in minutes. Without alerts, you won't know until users complain (or leave silently).

Why Reactive Monitoring Fails

Most teams check performance manually:

• "Let me run PageSpeed Insights real quick..."
• "The site seems fine to me"
• "We'll check performance next sprint"

This approach fails because:

• Performance issues often happen between manual checks
• Developers test on fast machines and fast connections
• Third-party scripts update without warning
• Traffic spikes cause performance degradation
• Nobody checks on weekends or holidays

What to Alert On

Critical Alerts (Wake Someone Up)

Metric	Threshold	Why
LCP	> 4.0s	Page is effectively broken for mobile users
Lighthouse Score	< 40	Something is seriously wrong
TTFB	> 3.0s	Server is likely overloaded or down
Error rate	> 5%	Pages are failing to load

Warning Alerts (Address During Business Hours)

Metric	Threshold	Why
LCP	> 2.5s	Crossed the "Good" threshold
CLS	> 0.1	Layout shifts affecting UX
INP	> 200ms	Interactivity degraded
Lighthouse Score	< 70	Below acceptable range
Page weight	> 3MB	Resource bloat detected

Trend Alerts (Review Weekly)

Metric	Condition	Why
LCP	Increasing 10%+ week-over-week	Gradual degradation
JS bundle size	Growing 20%+ month-over-month	Bundle bloat
Third-party count	New scripts detected	Unauthorized additions

Setting Up Alerts

With BadPageSpeed

1. Add your pages to monitoring
2. Set threshold alerts for each Core Web Vital
3. Configure notification channels (email, Slack)
4. Review alert history to tune thresholds

With Lighthouse CI

# lighthouserc.yml
ci:
  assert:
    assertions:
      categories:performance:
        - error
        - minScore: 0.7
      largest-contentful-paint:
        - warn
        - maxNumericValue: 2500
      cumulative-layout-shift:
        - warn
        - maxNumericValue: 0.1

With Custom Monitoring

// Report Web Vitals to your analytics
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendAlert(metric) {
  if (metric.name === 'LCP' && metric.value > 4000) {
    fetch('/api/alerts', {
      method: 'POST',
      body: JSON.stringify({
        metric: metric.name,
        value: metric.value,
        page: window.location.pathname,
        severity: 'critical'
      })
    });
  }
}

onLCP(sendAlert);
onINP(sendAlert);
onCLS(sendAlert);

Alert Fatigue: The Silent Killer

Too many alerts = ignored alerts. Prevent alert fatigue:

1. Set Meaningful Thresholds

Don't alert on every minor fluctuation. Lighthouse scores naturally vary 5-10 points.

2. Use Severity Levels

Not every alert needs to wake someone up at 3am:

• Critical → PagerDuty/phone call
• Warning → Slack channel
• Info → Weekly report

3. Include Context

Good alert: "LCP on /checkout increased to 5.2s (was 2.1s). Possible cause: new banner image added."

Bad alert: "Performance degraded."

4. Auto-Resolve

Alerts should auto-resolve when metrics return to normal. Nobody should have to manually close fixed alerts.

5. Review and Tune

Monthly: review all alerts fired. Remove noisy ones, add missed ones.

The Response Playbook

When an alert fires, have a plan:

Step 1: Verify (2 minutes)

Run a quick manual check — is it a real issue or a false positive?

Step 2: Identify (5-10 minutes)

• Check recent deployments
• Check third-party script changes
• Check server health
• Check CDN status

Step 3: Mitigate (immediate)

• Rollback recent deployment
• Disable problematic third-party script
• Scale up servers
• Purge CDN cache

Step 4: Fix (hours/days)

Address the root cause. Deploy a permanent fix.

Step 5: Postmortem

What happened, why, and how to prevent it. Update monitoring if needed.

Monitor What Matters

BadPageSpeed runs automated Lighthouse audits and alerts you when performance crosses your thresholds.

Set up performance alerts →