Slow is the new down.
No thresholds to guess. UptimeStatus compares last hour's p95 against your 7-day baseline every 10 minutes and flags anything twice as slow.
Pick a threshold, pick your poison.
Tools that make you alert on a fixed millisecond number leave you two bad options. Set it tight and every traffic spike pages you at 3am. Set it loose and a real regression cruises under it for weeks.
UptimeStatus does not ask for a number. Your monitor's own history is the threshold: the last hour's 95th-percentile response time is compared against the p95 of the preceding 7 days. Normal for your API, not normal in general.
Up, but slower. Now you know.
A bad database index, a saturated connection pool, a dependency that started timing out and retrying: none of these fail your health check. Every probe still returns 200, and every response takes three times longer than last week.
The trend check runs every 10 minutes across all your enabled monitors. When the last hour's p95 reaches at least 2x the baseline, it opens an incident with both numbers and the ratio, so the alert arrives with its own evidence.
How the regression check works.
- Automatic baseline built from the preceding 7 days of your own check results and recomputed on every run. Nothing to configure.
- p95, not averages the comparison uses 95th-percentile response time, so tail latency cannot hide behind a healthy mean.
- Every 10 minutes each enabled monitor with response-time history is evaluated, around the clock.
- A 2x regression bar an incident opens when the last hour's p95 is at least twice the baseline p95.
- Sample guard at least 5 data points required in both windows, so a quiet monitor cannot false-alarm off two slow requests.
- No alert storms while a degradation incident is open, the check does not re-open a duplicate every 10 minutes.
An early warning, not a false alarm.
A degradation incident is informational: it opens in "monitoring" status because your site is most likely still up. Your monitor is not marked down and your uptime percentage is untouched, so your team gets time to fix the slowdown before it becomes the outage.
Alerts that carry their own numbers.
Every degradation incident stores the recent p95, the baseline p95, and the cause as structured data alongside the human-readable summary. Route it to Slack for people or to a webhook for machines; either way, the evidence travels with the alert.
The response times behind it come from your regular checks, kept with 90 days of uptime history.
{
"cause": "Response time degraded: p95 over the
last hour (612ms) is 2.4x the 7-day
baseline (255ms)",
"status": "monitoring",
"impacted_checks": [{
"type": "performance",
"recentP95": 612,
"baselineP95": 255
}]
}Performance monitoring, answered.
Why p95 instead of average response time?
Averages hide the pain. A monitor can average 200ms while one request in twenty takes 3 seconds, and those are the requests your users remember. p95 tracks the slow tail directly, on both sides of the comparison.
How is the baseline calculated?
From your own check results over the preceding 7 days, excluding the last hour. Excluding the current hour matters: an ongoing regression cannot drag its own baseline up and mask itself.
What exactly triggers an incident?
The 95th-percentile response time of the last hour reaching at least 2x the 7-day baseline p95, with a minimum of 5 samples in each window. The incident records both numbers and the ratio between them.
Will it page me every 10 minutes while things are slow?
No. If a degradation incident for that monitor is still open, the check skips it instead of opening a duplicate. You get one incident per slowdown, not one per evaluation.
Is a slowdown treated the same as downtime?
No. A degradation incident opens with the informational "monitoring" status, because the monitor may well still be up. Your status page and uptime numbers are not declared down just because responses got slower.
Do I need to set anything up?
No. Any enabled monitor that records response times, which HTTP uptime checks do on every probe, is covered automatically. There is no threshold field to fill in anywhere.
Pairs well with.
Uptime monitoring
The response times this feature analyzes come from your uptime checks, as often as every 30 seconds.
Learn moreLighthouse monitoring
Baseline comparison watches your servers. Lighthouse watches what the browser does with your pages.
Learn moreNotifications
Degradation incidents route through the same 10 channels as everything else, from Slack to PagerDuty.
Learn moreStart monitoring in under 2 minutes.
No credit card required for the self-hosted, open-source version.