A website can be "up" and simultaneously unusable. If your homepage takes 12 seconds to load, your checkout API times out at peak load, or your mobile app's backend responds in 8 seconds, users leave — and the incident often goes undetected because standard uptime monitors report the endpoint as available.
Performance monitoring closes this gap. This guide covers what to measure, what thresholds to set, and how to build alerts that catch degradation before users report it.
Uptime Monitoring vs Performance Monitoring
Uptime monitoring answers a binary question: did the endpoint respond with a success code? An HTTP 200 within any timeframe counts as "up." A 15-second response time that makes your application effectively unusable still reports as available.
Performance monitoring measures response time on every check and alerts when that time exceeds acceptable thresholds. It tracks degradation trends over time, surfaces slow endpoints before they become failures, and provides historical data for diagnosing performance regressions.
Both are necessary. Uptime monitoring catches hard failures (the site is down). Performance monitoring catches soft failures (the site is up but unusable).
What Response Time Monitoring Checks
Every time a performance monitor runs, it records:
- Total response time — time from request initiation to response completion
- Time to first byte (TTFB) — how long the server took to start responding
- DNS resolution time — time spent resolving the domain (relevant for diagnosing DNS-layer slowdowns)
- Connection time — TCP handshake and TLS negotiation duration
These breakdown metrics help distinguish between server-side slowness (high TTFB), network issues (high connection time), and DNS problems (high DNS resolution time) — all of which can manifest as "slow response" at the surface level.
What Response Time Thresholds to Set
There is no universal threshold — it depends on your endpoint type, user expectations, and your service level objectives. These are reasonable starting points:
Marketing and documentation pages
- Good: under 800ms
- Acceptable: 800ms–2,000ms
- Alert threshold: above 2,000ms
- Critical: above 4,000ms
Users expect static content quickly. Google's Core Web Vitals flag pages over 2.5 seconds (LCP) as needing improvement. Slow marketing pages affect both user experience and SEO rankings.
Application UI (authenticated dashboards, SaaS products)
- Good: under 1,000ms
- Acceptable: 1,000ms–3,000ms
- Alert threshold: above 3,000ms
- Critical: above 6,000ms
Users tolerate slightly higher latency in authenticated apps but still abandon sessions during multi-second delays.
REST APIs (read endpoints)
- Good: under 200ms
- Acceptable: 200ms–500ms
- Alert threshold: above 500ms
- Critical: above 1,000ms
API consumers (mobile apps, frontend clients, third-party integrations) have no inherent patience for slow APIs. Mobile app backends in particular must respond fast to accommodate network overhead on top of your server latency.
REST APIs (write/mutation endpoints)
- Good: under 500ms
- Acceptable: 500ms–1,500ms
- Alert threshold: above 1,500ms
- Critical: above 3,000ms
Write operations involve database transactions and often downstream service calls. Slightly higher acceptable thresholds are reasonable, but alerts should still fire before user-perceptible slowness reaches the 3-second mark.
Performance Degradation Detection
A single slow response is noise. A sustained trend toward higher response times is signal. Effective performance monitoring distinguishes between one-off spikes (a brief server GC pause, a momentary database lock) and genuine degradation (a memory leak, an unindexed query introduced by a recent deploy, a dependency slowdown).
Detection strategies:
Absolute threshold alerts fire when a single measurement exceeds a set value. Simple, low-latency, high false-positive rate.
Sustained threshold alerts fire when response time exceeds a threshold for N consecutive checks or over a rolling time window. Reduces false positives from one-off spikes.
Trend alerts fire when response time increases significantly compared to a baseline (e.g., 50% higher than the 24-hour rolling average). Catches gradual degradation that stays under absolute thresholds.
Vigilmon's response time monitoring uses check-interval measurements with historical graphing, allowing you to correlate performance changes with deployments and identify the onset point of degradation.
Slow API Alerts: What to Monitor
Not all endpoints deserve equal monitoring. Prioritise:
Revenue-critical paths: payment processing, checkout, subscription management. A slow checkout is direct lost revenue.
Authentication endpoints: login and token refresh. If your auth API is slow, users can't access your product at all.
High-traffic read APIs: the endpoints your mobile app or frontend calls most frequently. Slowness here multiplies across every active user.
Third-party integration webhooks: if you receive webhooks from payment providers, CRMs, or notification services, a slow webhook receiver may cause the sender to retry or drop events.
Health check endpoints: if your load balancer uses a health check endpoint, its response time affects routing decisions. A slow health check may cause premature instance removal.
Setting Up Response Time Monitoring in Vigilmon
Vigilmon includes response time monitoring on all HTTP/HTTPS checks.
To configure response time alerts:
- Add an HTTP/HTTPS monitor for your endpoint
- Set your check interval (1 minute on Pro)
- Under Alert conditions, set a response time threshold in milliseconds
- Vigilmon records response time on every check and graphs it historically
- Configure notification channels for threshold breaches
The response time history view shows you response time over the past 24 hours, 7 days, or 30 days, with check-level granularity. You can visually identify when degradation started — and correlate it with a specific deployment time.
Response Time Monitoring Best Practices
Set thresholds per endpoint type. A 500ms threshold appropriate for an API is unnecessarily strict for a server-rendered page with database calls. Configure per-monitor thresholds, not one global value.
Alert at 80% of your SLA. If your SLA commits to sub-500ms API responses, alert at 400ms — so you have time to investigate before the SLA is breached.
Monitor from multiple regions. Response time varies by geography. A monitor running only from the US misses performance problems affecting European users. Multi-region checks give you an accurate picture of global performance.
Track response time trends after every deploy. Use your response time history to confirm that each production deploy does not introduce latency regressions. Even small regressions compound over time.
Separate performance alerts from outage alerts. Route performance threshold alerts to your engineering channel for investigation; reserve your highest-urgency channels for hard downtime alerts.
Performance Monitoring Metrics Summary
| Metric | What it tells you | |---|---| | Total response time | End-to-end user-perceived latency | | Time to first byte | Server processing speed | | DNS resolution time | DNS health and caching effectiveness | | Connection time | Network path and TLS overhead | | Response time trend | Degradation onset and rate |
Performance monitoring is the difference between knowing your service is reachable and knowing it is actually usable. Start with response time thresholds on your highest-traffic endpoints — and extend coverage as you identify which endpoints matter most to your users.
Add performance monitoring to Vigilmon — response time tracking is included on all HTTP monitors, starting on the free tier.