Your users almost never tell you when your site is slow. They just leave. Research consistently shows that bounce rates spike after just 3 seconds of load time — and for mobile users, the tolerance is even thinner. By the time a customer emails you about a problem, dozens of others have already moved on quietly.
The only way to stay ahead of that is solid website performance monitoring. Not checking Google Analytics once a week, but real-time visibility that tells you something is wrong before it snowballs into lost revenue.
This guide walks you through how to set up meaningful performance alerts — what to monitor, what thresholds to set, and which tools to use.
Why Reactive Monitoring Always Loses
Most developers discover performance problems the wrong way: a user complains, you check the site, something feels slow, you dig through logs for the next hour. That process wastes time you don't have.
Proactive website performance monitoring flips that script. You define what "normal" looks like for your site — response times, error rates, memory usage — and you get alerted the moment something drifts outside that range. You find the fire before the smoke reaches your customers.
The difference matters more than most people realize. A 1-second slowdown in response time can reduce conversions by 7%. A 500 error that runs for 20 minutes unchecked can crater an entire day's traffic, especially if it hits during peak hours.
The Four Metrics Worth Alerting On
Not everything needs an alert. Too many notifications and you start ignoring them. Focus on the metrics that actually predict user pain.
1. Uptime and Availability
This is the baseline. If your site is down, you need to know in under a minute — not when someone tweets at you. A good uptime monitor checks from multiple locations every 30–60 seconds and sends an immediate alert when a check fails from more than one location (to filter false positives from single-node blips).
Set alerts for: two consecutive failed checks from at least two geographic regions.
2. Response Time (TTFB)
Time to First Byte is one of the most actionable server-side metrics. It tells you how long the server takes to respond to the very first request — before any assets load, before any JavaScript runs. A TTFB under 200ms is healthy. Over 600ms and you have a problem worth investigating. We covered the full impact of this in why your TTFB is costing you conversions.
Set alerts for: TTFB consistently above 500ms over a 5-minute rolling window.
3. Error Rate (4xx and 5xx)
A handful of 404s are normal. A sudden spike in 500 errors is not. Alert on the rate, not individual occurrences. If your error rate jumps from 0.1% to 5% in a short window, something broke — a deployment, a plugin update, a database connection failing under load.
Set alerts for: 5xx error rate exceeding 2% over any 3-minute window.
4. Server Resource Usage
CPU and memory spikes often precede slowdowns by several minutes. If your CPU is pegged at 95% for 10 minutes, response times are about to suffer — if they haven't already. Watching resource usage gives you a leading indicator rather than a lagging one.
Set alerts for: CPU sustained above 85% for more than 5 minutes, or memory above 90% for more than 3 minutes.
Tools for Real-Time Website Performance Monitoring
You don't need to build monitoring from scratch. Several tools do this well.
UptimeRobot
Free tier covers 50 monitors with 5-minute check intervals. Good for uptime and basic response time tracking. Paid plans bring 1-minute checks and richer alerting channels.
Better Uptime
Checks every 30 seconds, includes on-call scheduling, and has a clean incident management interface. Particularly useful for teams where multiple people need to be in the loop on alerts.
Grafana + Prometheus
The most powerful option if you want full control. Prometheus scrapes metrics from your server and applications; Grafana visualizes them and fires alerts based on rules you define. The setup takes longer, but the visibility is unmatched. You can alert on virtually any metric your stack exposes.
A basic Prometheus alerting rule looks like this:
groups: - name: performance rules: - alert: HighResponseTime expr: http_request_duration_seconds{quantile="0.95"} > 0.5 for: 5m labels: severity: warning annotations: summary: "95th percentile response time above 500ms"Datadog and New Relic
Full observability platforms. Better suited to larger applications or teams that want APM (application performance monitoring) alongside infrastructure metrics. Both offer anomaly detection that can alert on unusual patterns even without predefined thresholds — useful when your traffic patterns are irregular.
How to Set Thresholds That Don't Cause Alert Fatigue
The most common mistake in website performance monitoring is setting thresholds too tight. You end up with a flood of notifications for minor fluctuations, and eventually you start muting alerts entirely. Then the real problems slip through.
A smarter approach:
- Baseline first. Run your monitoring tool for 2–4 weeks before setting alert thresholds. Look at your 95th percentile response times, typical error rates, and normal CPU patterns. Set thresholds relative to your baseline — not generic industry numbers.
- Use rolling windows. Alert on sustained conditions, not single data points. A TTFB spike that lasts 10 seconds is noise. One that persists for 3 minutes deserves attention.
- Separate warning from critical. Warning alerts can go to Slack. Critical alerts — site down, high error rate — should go to SMS or PagerDuty. Make it easy to triage severity at a glance.
- Revisit thresholds after major changes. A new caching layer, a CDN addition, or a significant code deployment all shift your baseline. Update your thresholds accordingly.
Layering in Server-Level Visibility
Third-party uptime checkers test your site from the outside — exactly how your users experience it. But you also need visibility into what's happening inside the server.
Resource graphs, per-site CPU and memory breakdowns, and activity logs give you the context to understand why something slowed down, not just that it did. On managed hosting, this kind of server-level monitoring is usually built in — so you don't have to wire up Prometheus just to see that your database process is consuming 80% of available memory at 2 AM.
For a deeper look at how Core Web Vitals connect to the server side, see Core Web Vitals and Hosting: Why Your Server Is Either Helping or Hurting Your Scores.
Alerting Is Only Half the Picture — You Also Need a Response Plan
An alert at 3 AM is useless without a playbook. When you get notified that response times have doubled, what do you actually do first?
Keep a short incident checklist somewhere accessible:
- Check whether the problem is isolated to one page, one geographic region, or sitewide.
- Look at server resource graphs for the time the alert fired — CPU, memory, I/O.
- Check recent deployments or cron jobs that ran around that time.
- Review error logs for unusual patterns (database connection failures, PHP fatal errors, etc.).
- If the site is down entirely, check whether a recent backup is available for quick rollback.
Having this list in a shared doc means any team member can start triaging immediately — not just the person who built the server.
The Takeaway
Good website performance monitoring isn't about watching dashboards all day. It's about building a system that does the watching for you and surfaces problems at the right moment, with enough context to act fast.
Start with uptime checks, add TTFB and error rate monitoring, establish baselines before setting thresholds, and build a simple response playbook your team can actually follow. That combination will catch the overwhelming majority of performance problems before your users do.
If you want to understand what's worth optimizing once your monitoring is in place, Website Speed Optimization: What Actually Moves the Needle is a solid next read.
For uptime monitoring details, see our uptime monitoring overview.
