interactive playground

Shape a metric, then watch detection happen.

Dial in a series that looks like one of yours, turn the detector's real knobs, and see the corridor of normal, what gets flagged, and whether an alert would fire. The math is the actual detectkit detector, ported to run entirely on this page — nothing is sent anywhere.

metric expected range flagged anomaly injected (missed) alert fires hover to see the window a point is judged by · scroll to zoom, drag to pan, double-click to reset

hover a point to inspect its window & verdict

—

caught

—

false alarms

—

flagged pts

—

flag rate

—

MCC

your metric

rhythm iThe repeating shape of your metric — flat, a daily cycle, weekly, business-hours, or spiky counts. noise iHow much random jitter sits on top of the rhythm — higher noise widens the normal band. trend iA slow upward or downward drift in the level over the whole series. interval iThe spacing between points (the metric grid step), e.g. one point every hour. incident iThe kind of problem to inject — a spike, dip, sustained step, slow drift, or a cluster. size iHow large the injected incident is relative to normal — drag up to make it more obvious.

detector

detector iWhich statistic builds the corridor: mad (robust median), zscore (mean ± σ), or iqr (quartile fences). threshold iHow wide the corridor is, in spread units — higher means fewer flags, lower means more sensitive. window_size iHow many recent points the corridor is computed from — longer is steadier, shorter adapts faster. recency weighting iWhether recent points count more than older ones when building the corridor (off, exponential, or linear). detrend iRemoves a local slope before judging a point, so a steady trend is not flagged as anomalous. smoothing iSmooths the series (EMA or SMA) before detection, so single-point noise does not trip the band. seasonality grouping iConditions the corridor on a seasonal key (hour, or hour+day-of-week) so each time-of-day has its own normal.

alerting

consecutive_anomalies iHow many grid-adjacent flagged points in a row are needed before an alert actually fires.

An alert fires only when this many grid-adjacent flagged points form a run — so a single noisy blip never pages anyone. Each qualifying run is one alert, marked with a ▼ on the chart.

// effective config

// the same windowed statistics that run in production — current point excluded from its own window, NaN gaps skipped, seasonality & recency applied per point
// detection runs only in the effective zone (past warm-up, dimmed on the left); caught = injected incidents a flag landed on · flag rate = share of judged points flagged · MCC = correlation of flags with the truth · the alert needs consecutive_anomalies grid-adjacent flags

Get started for real Read the detectors guide