Alert Rule Conditions: Response Time
A response time alert rule fires when a check takes longer than a threshold you define. This article explains how to configure response time rules and recommends sensible starting thresholds.
How It Works
After every check, PulseAPI records the response time in milliseconds. If that response time exceeds your threshold (or falls below it, depending on the operator), the rule fires.
Configuring a Response Time Rule
- In the alert rule form, set Condition Type to Response Time.
- Choose an Operator:
- Greater than (>) — alert when response time exceeds the threshold (most common)
- Greater than or equal to (≥)
- Less than (<) — useful if you want to detect unusually fast responses (rare)
- Enter the Threshold in milliseconds.
- Configure the rest of the rule (scope, channels, cooldown, priority).
Recommended Starting Thresholds
| Use Case |
Threshold |
Priority |
| Critical slowness — definitely down or broken |
10,000ms (10s) |
Critical |
| Serious degradation — users likely affected |
3,000ms |
High |
| Performance warning — investigate |
1,500ms |
Medium |
| SLA baseline check |
Your SLA target × 0.8 |
Low |
These are starting points. Review your monitor's actual baseline response times (check the Response Time Chart on the monitor detail page) and set thresholds that are meaningfully above normal — a threshold too close to baseline will generate false positives.
Response Time vs. Timeout
The monitor's Timeout setting is different from a response time alert rule:
- Timeout — the maximum time PulseAPI waits before abandoning the request and recording a failure. A timeout is a hard failure.
- Response time alert rule — fires when the response comes back, but took longer than expected. The check still succeeded; it just wasn't fast enough.
For example: a 30-second timeout + a 2,000ms alert rule means: any response after 2s fires the rule; any response after 30s is recorded as a timeout failure.
Related Articles
Still have questions? Contact support.
Related Articles
Alert Rule Conditions: Status Code
A status code alert rule fires when the check receives an HTTP status code that matches (or doesn't match) your condition. This is the most direct way to detect when an endpoint is down. How It Works After every check, PulseAPI records the HTTP ...
Alert Rule Conditions: SSL Certificate Expiry
An SSL expiry alert rule fires when your monitor's SSL certificate will expire within a specified number of days. This gives you advance warning before your certificate expires and causes real failures. How It Works PulseAPI reads the SSL certificate ...
Creating an Alert Rule
This article walks you through creating an alert rule in PulseAPI. Alert rules define when PulseAPI creates an incident and sends notifications. Prerequisites: At least one notification channel must exist before you can assign it to a rule. See ...
Auto-Tuning Alert Thresholds
Auto-Tune analyzes your historical check data and incident history for a rule, then suggests or automatically applies threshold adjustments to reduce false positives. It's available on Professional and Team plans. What Auto-Tune Does Auto-Tune looks ...
Enabling and Disabling Alert Rules
You can enable or disable any alert rule without deleting it. A disabled rule doesn't evaluate checks or create incidents, but its configuration is preserved for when you need it again. Disabling a Rule In the left sidebar, click Alerts, then Alert ...