Establish a normal range first
Response time naturally changes with traffic, cache state, location, and external dependencies. A single number is less useful than a pattern. Review recorded checks over a day or week to understand a normal range for each important URL.
Monitor different pages separately because they do different work. A lightweight homepage, a database-backed dashboard, and a checkout route should not be judged by the same expectation.
Watch for changes, not only absolute numbers
A sudden jump from a familiar range is often more actionable than a universal target. Compare the latest response time with recent minimum, average, and maximum values. Look for repeated spikes rather than reacting to one slow observation.
When a spike appears, line it up with deployment times, traffic changes, database activity, cache misses, queue depth, or an upstream provider event. The monitor provides a timestamped clue; service telemetry provides the deeper explanation.
Use timeouts carefully
A timeout is not just a slow response. It means the monitoring request did not finish before the configured limit. Set the limit high enough for the real behavior of the page, but low enough that a stuck service is reported quickly.
Do not solve a performance regression by only raising the timeout. First identify why the page is slow, then adjust the monitor only if the original threshold was unrealistic for the expected user experience.
Turn a slow-page signal into action
Use the response-time history to guide a focused investigation. Start with the route that is slow, then inspect the application and the dependencies that route uses.
- Compare the slow period with recent deployments and configuration changes.
- Inspect server, database, cache, queue, and upstream dependency metrics.
- Check whether the problem affects one route or every monitored page.
- Confirm improvement with new observed checks after the fix.