Should we start with RUM or backend APM?

Start with the journey you care about most (usually checkout/login). If you can only do one first, ship backend tracing/metrics with `OpenTelemetry` so you can debug quickly, then add RUM to catch device/network realities and segment the pain. The win is correlation, not picking a tool.

What percentile should we alert on: p95 or p99?

Use **p95** for primary alerting (less noisy) and track **p99** for “VIP pain” and tail-latency work. Tail issues often come from GC pauses, DB lock contention, or downstream jitter—p99 is where those show up.

How do we avoid alert fatigue with performance monitoring?

Alert on **burn rate** and **regressions**, not every small spike. Tie alerts to a specific journey SLO, add segmentation (region/device), and require a minimum duration (e.g., 10–15 minutes) so you page on sustained user impact.

How do we prove performance work is worth it?

Put latency and business KPIs side-by-side: `p95 checkout` next to conversion/revenue/session. Then run controlled rollouts (canary or feature flag) and compare cohorts. Even a simple before/after with deployment markers is usually enough to stop the “performance is a nice-to-have” debate.

Performance-optimization · Dec 17, 2025 · 8 minute read

The Pager Didn’t Go Off—Your Checkout Still Got Slow: Monitoring That Catches Bottlenecks Before Users Do

Most teams alert on CPU and 500s, then act surprised when conversion drops. Here’s how to wire performance monitoring to user-facing metrics, catch bottlenecks early, and ship optimizations with measurable business impact.

Back to all posts

The Pager Didn’t Go Off—Your Checkout Still Got Slow: Monitoring That Catches Bottlenecks Before Users Do

Key takeaways

Implementation checklist