Real Browser and Uptime Checks monitor:
- Average Response Time
- Slowest Response Time
- Fastest Response Time
These times represent the total time for the check to run. If the Real Browser or Uptime check has multiple steps, the response time represents the sum of the load time for each page accessed during the check.
By default Rigor deems any check that takes longer than 120 seconds as a failure and alerts according to the specified notification settings.
We can use a custom Response Time Monitor to define a lower threshold. If a check’s response time exceeds the time specified on the Response Time Monitor, the check will be marked as a failure and alert accordingly.
If a check has multiple steps and monitors multiple pages, we can use Threshold Monitoring to set response time monitors on individual pages within a user flow. If any of these pages do not meet the set threshold, the whole check will be marked as a failure and alert accordingly.
Should I set a response time monitor?
Response time monitors affect alerting, making alerts and notifications more aggressive and proactive based on the time thresholds we set. Alerts affect the Uptime percentage reported in Daily, Weekly, or Monthly performance reports.
As a best practice, we should only enable custom response time monitors if we have a good idea of our baseline response time and if we want to be notified any time the site takes longer than that baseline.
For example, if we’re operating around an SLA that our site must load in less than 40 seconds at all times we should consider enabling a custom response time monitor of 40,000 ms.
If we know our average response time is 15 seconds but we don’t need to take action if the site loads slower than 15 seconds, we should not enable a response time monitor. We can rely on reports in the app to see how often our site’s response time is above average.