Response time alerts

A service can answer every check and still be too slow for its users. A response time alert turns the monitor degraded when its checks take longer than a threshold you choose, and sends a degraded alert to its channels.

Available on every plan, for HTTP, TCP, ping, DNS, gRPC, database, mail and Redis monitors. Push, group and AI model monitors have no response time threshold (an AI model monitor has its own time-to-first-token limit).

Set the threshold

Open the monitor (Edit, or Add monitor for a new one) and go to the Alerts step. It holds, from top to bottom:

1. Retries before down — how many failed checks in a row are tolerated before the monitor is down: None, 1, 2, 3, 4 or 5 (1 by default).
2. Response time — Mark as slow above, in milliseconds. The monitor’s response times over the last 7 days (average, p95, p99) are shown above the field to help you choose. Pick a preset (500 ms, 1 s, 1.5 s, 3 s), type any value between 50 and 60 000 ms, or choose Off.
3. The alert channels that receive the monitor’s alerts.

The regions the checks run from are chosen in the Schedule step, next to the interval.

Choosing a value

Start a little above the p95 shown in the dialog: the threshold should catch an unusual slowdown, not your normal slowest checks.

When the alert fires

The threshold is judged per region, like failures:

• A check is slow when it succeeds and takes strictly more than the threshold.
• The region turns degraded after max(2, retries + 1) slow checks in a row. With the default 1 retry, that is 2 checks; with 3 retries, 4 checks. One isolated slow check never alerts.
• One slow region is enough to make the monitor degraded. Slowness never counts toward the majority rule: a monitor that is slow everywhere is degraded, never down.
• The monitor is back to up at the first check under the threshold — no confirmation window on the way back.
• A real failure always wins: a check that fails follows the usual retry rule and turns the monitor down.

The same cooldown as other alerts applies: a monitor that keeps going in and out of slowness does not send an alert at every check.

What the alert says

The degraded alert names the cause, the measured time and the regions:

Response time 2 340 ms is above the 1 500 ms threshold (Paris, Frankfurt)

The e-mail shows the threshold you set instead of the default 2 s. A webhook receives the monitor.degraded event with four more fields, so a receiver can route slowness apart from failures:

{
  "event": "monitor.degraded",
  "monitor": { "name": "API", "url": "https://api.example.com" },
  "region": "fr-dc3",
  "timestamp": "2026-10-17T08:12:44.000Z",
  "reason": "latency_threshold",
  "latencyMs": 2340,
  "thresholdMs": 1500,
  "slowRegions": ["fr-dc3", "de-fra"]
}

Status pages

By default slowness is public: a slow monitor shows degraded (amber) on the status pages it belongs to — your users feel it, the page says it.

Untick Show slowness on status pages under the threshold to keep it internal: the monitor then shows as operational on public pages while the dashboard, the alerts and the monitor’s page still report it as degraded. A failure is always public, whatever this setting.

Uptime and SLA are not affected

A slow check is a successful check. It counts as up in uptime %, in reports and in SLA figures: the service answered. Response time alerts tell you about quality, not availability.

On the monitor page

The response time chart draws the threshold as an amber dashed line, so you can see how close your checks run to it.

Without a threshold

A monitor with no threshold (Off) never sends a response time alert. Lists and the check history still show it as Slow (amber) when its last check took 2 seconds or more, as a visual hint only.

Abnormal latency (Max and Enterprise)

A fixed threshold only catches what you set it for. A service that usually answers in 180 ms and now takes 600 ms is in trouble, yet stays under a 1 s threshold. Tick Abnormal latency under the threshold, and OKStatus watches for that too.

• What it learns: for each region, the hourly p95 of the last 28 days, for the same hour of the same day of the week — Monday 9 am is not Sunday 3 am. The usual range is the 10th to 90th percentile of those values. With too few weeks it falls back to the same hour every day, then to every hour.
• Learning: alerts start after 7 days of history. The form shows the progress (“3 of 7 days · alerts active from …”), then the usual range at this hour once learnt.
• When it alerts: every 5 minutes, the p95 of the last 15 minutes (at least 3 successful checks) is compared to the top of the usual range. It is abnormal when it is more than 1.5 times that top and more than 100 ms above it. 3 evaluations in a row (about 15 minutes) send a degraded alert; 2 evaluations back in range close it, and the recovery is sent if nothing else keeps the incident open.
• What it says: “p95 response time 640 ms over 15 min (Paris) is 2.3× the usual 150–280 ms at this hour”. The e-mail is titled slower than usual; the webhook carries "reason": "latency_anomaly", latencyMs (the 15-minute p95), usualMs (low, high) and slowRegions.
• What it does not do: it does not change the monitor’s status or its uptime, and it never sends a second alert while an incident is already open — it only keeps that incident open until the response time is back in its usual range.

On the monitor page, the response time chart draws the usual range as a cyan band behind the first region’s line.

Below Max the option is visible but locked, with a link to the plans. If the organization moves to a lower plan, the evaluations stop and any open anomaly is released within 15 minutes.

API, Terraform and MCP

Setting	REST API and MCP field	Terraform attribute
Threshold (ms, null = off)	latencyThresholdMs / latency_threshold_ms	latency_threshold_ms
Show slowness on status pages	latencyPublic / latency_public	latency_public
Abnormal latency (Max and Enterprise)	latencyAnomaly / latency_anomaly	latency_anomaly

See Monitors API, the Terraform provider and the MCP connector.