Anomaly Detection Beta
Anomaly detection learns a monitor's normal behavior from its own history and flags checks that fall far outside it — even when the monitor never goes down. It works on uptime monitors (response times) and cron monitors (run durations). This feature is currently in beta.
What It Is
A learned expected range instead of a fixed threshold
Instead of asking you to guess a millisecond threshold, FlareWarden builds a baseline from the monitor's own checks: what response times look like at each hour of the week for uptime monitors, or how long recent runs took for cron jobs. Checks far outside that range are flagged as anomalies.
Uptime Monitors
Response-time baselines per hour of the week. A slow Tuesday afternoon is judged against other Tuesday afternoons, not a global average.
Cron Monitors
Run-duration baselines from the last 50 completed runs. Catches jobs that still succeed but take far longer than their own normal.
Anomalies are not incidents. They never affect your uptime percentage, never open incidents, and never trigger cross-region validation. They are a parallel, quieter signal.
Enabling It
Per monitor, one toggle, one slot
From the Monitor Page
Open the monitor and use the Anomaly Detection panel. It explains what you'll get, shows your current monitor usage with the pending +1, and lets you pick a sensitivity and alert preference before enabling.
From the Add Website Wizard
When creating a new monitor, check the Anomaly Detection option on the create step. The usage preview updates live so you can see the extra slot before you confirm.
Slot Accounting
Each monitor you enable anomaly detection on uses one additional slot from your plan's unified monitor pool — the same pool uptime, content, cron, and dependency monitors draw from. Enabling it on a parent monitor and on one of its cron monitors uses two slots.
Disabling it frees the slot immediately. The learned baseline is kept, so re-enabling later is instant.
At Your Monitor Limit?
If your pool is full, the enable panel offers a path forward: upgrade your plan, or — on any paid plan — add 10 extra monitors for $5/mo from your billing page. Free accounts upgrade to a paid plan first; add-ons aren't available on the free tier. See Plans & Billing for details.
How Baselines Work
Where "normal" comes from
Uptime: Hour-of-Week Bands
For each of the week's 168 hours, FlareWarden computes an expected response-time range (roughly the 10th to 90th percentile) from your monitor's successful checks over the trailing six weeks. Baselines refresh nightly. Down checks, checks during maintenance windows, checks marked as false alarms, and previously flagged anomalies are excluded — so today's anomaly never becomes next week's "normal."
Cron: Last 50 Runs
Cron baselines use the median run duration of the last 50 completed runs plus a robust measure of deviation, so a single outlier run doesn't skew the baseline. At least 10 completed runs with duration are required before scoring starts. Relative and absolute floors prevent trivial flags — a 2-second job that takes 3 seconds is never an anomaly.
The Learning Ladder
Learning. Collecting data. No band on the chart, no anomaly events. The chart shows a learning indicator.
Basic range. A global (non-seasonal) expected range is active. Detection works, but weekday and weekend patterns aren't separated yet.
Seasonal. Full hour-of-week baselines — each hour of each weekday gets its own expected range. This needs about 21 days of history and enough checks to fill those buckets, so a low-frequency monitor (say, one check every 30 minutes) reaches it later than a fast one.
Monitors that already have history skip the wait: baselines are computed from the data FlareWarden has already collected, so long-running monitors get value immediately after enabling.
Sensitivity
One three-position setting per monitor
Flags only extreme deviations from the expected range. Choose this for noisy monitors or when you only want to hear about the truly dramatic slowdowns.
The balanced default, tuned to bias against false positives. A good starting point for almost every monitor.
Flags smaller deviations sooner. Use for latency-critical endpoints where a modest sustained slowdown already matters.
At every level, slowness is only flagged on the upper side (faster-than-normal is never an anomaly), and a confirmed event requires the deviation to persist across consecutive checks.
Reading the Chart
What each visual element means
Expected-Range Band
The shaded band shows the learned expected range for each point in time. The response-time line stays its usual color while it's inside the band.
Amber — Watching
Checks outside the range that haven't persisted long enough to confirm. No event is created and no alert is sent — the chart is just showing you what it's watching.
Red — Confirmed Anomaly
The deviation persisted across consecutive checks. An event is recorded in the anomaly log, and alerts fire for members who opted in.
Anomaly Lane & Log Card
A strip under the uptime and maintenance lanes marks anomaly windows on the timeline. Below the chart, the anomaly log card lists each event with its window, observed vs. expected range, and deviation (for example, "4.1× above normal").
Mark Expected
Teach the model about planned slowness
Some slowdowns are intentional — a load test, a batch import, a deploy that briefly warms cold caches. Every event in the anomaly log has a Mark expected action. Marking an event does two things:
- The event is labeled as expected in the log, so it doesn't read as a real problem later.
- The affected checks are excluded from future baseline computation, so your planned slowness doesn't widen the expected range going forward.
Alerts
Email and webhooks, opt-in per member
Email Alerts
Each team member controls their own Anomaly alerts toggle in notification settings. When a confirmed anomaly occurs, opted-in members receive an email with the window, observed vs. expected values, and a link to the monitor. A short “back to normal” recovery email follows when the monitor returns to its normal range, noting how long the slowdown lasted.
Webhooks
Confirmed anomalies fire the
anomaly.detected
webhook event, and
anomaly.resolved
fires when the monitor returns to its normal range.
Subscribe to either from any webhook's event list,
alongside your existing events. The
anomaly.resolved
payload is the same shape with a non-null
ended_at. The
anomaly.detected
payload looks like this (illustrative — see your
webhook's test delivery for the exact shape):
{
"event": "anomaly.detected",
"timestamp": "2026-07-02T14:12:00Z",
"data": {
"monitor_id": "mon_abc123",
"kind": "uptime",
"entity_id": "ent_def456",
"entity_name": "example.com",
"started_at": "2026-07-02T14:12:00Z",
"observed_min_ms": 412,
"observed_max_ms": 589,
"expected_lo_ms": 118,
"expected_hi_ms": 176,
"deviation": "4.1x",
"severity": "anomaly"
}
}See Webhooks for delivery, signing, and retry behavior.
Frequently Asked Questions
Does it affect my uptime percentage?
No. Anomalies never change uptime numbers. Your availability reporting stays exactly as it is.
Does it open incidents?
No. Anomalies are recorded in their own log and never create incidents, appear as downtime, or trigger cross-region validation.
What happens when I disable it?
The monitor slot is freed immediately. The learned baseline and past anomaly events are kept, so if you re-enable later there's no new learning period.
What happens if I downgrade my plan?
If the downgrade would leave your monitor pool over-committed, you'll be asked to free slots first — by disabling anomaly detection on some monitors or deleting monitors — before the downgrade completes. Disabling an anomaly overlay is the gentler option: the monitor itself keeps running.