Catch the spike
before it pages you.

Runs on a fresh machine with nothing to provision — the full project is in examples/quickstart-duckdb. Swap the profile for ClickHouse, Postgres, MySQL or a hybrid warehouse when you're ready — the four commands don't change. DuckDB guide →

AI-native: build metrics with an assistant, out of the box.

One command sets up Claude Code for your project folder — a CLAUDE.md, a .claude/rules/detectkit/ reference, and five skills: dtk-setup-project (configure your database), dtk-new-metric (scaffold a metric), dtk-tune (dial in a detector by hand in an interactive browser cockpit — with autotune built in), dtk-autotune (search for the best detector automatically), and dtk-feedback (file a redacted bug report or feature request upstream). Now an assistant writes metrics, tunes detectors, wires up alerts, and reports issues with full knowledge of detectkit. Re-run it after an upgrade to refresh the context.

Ask your pipeline what fired — and why.

dtk mcp is a strictly read-only Model Context Protocol server over your _dtk_* state. Point Claude Code, Claude Desktop or any MCP client at it, and your assistant answers questions from the real pipeline — no writes, no dashboards, no data leaving your infra. MCP guide →

A load → detect → alert run, in one tree.

The real output of dtk run — a load → detect → alert tree with cyan step headers and colored status lines. Idempotent: it resumes from the last saved point.

Robust statistics, not magic.

Every detector learns a corridor of normal from recent history, then flags the moment a metric steps outside it. Switch the detector to see the kind of metric it's built for.

// the statistical corridors are recomputed per window with seasonality grouping & recency weighting — newer points count more; autoreg refits its forecast per point
// each detector is shown on the metric shape it handles best — robust, bell-shaped, skewed, pattern-driven or hard-bounded
// opt-in stabilization keeps a sustained incident from widening its own corridor and masking its own tail

Play with the real tuning cockpit.

The playground is dtk tune — the same cockpit the tool ships — running on a synthetic metric you shape in your browser. Turn the detector's real knobs, watch the corridor of normal and what gets flagged, confirm alerts, mark incidents, and read the live catch-rate / false-alert metrics — nothing is sent anywhere.

Dial in a detector on your real data.

dtk tune --select <metric> opens a browser cockpit on the metric's real history. Turn a knob and the corridor recomputes live, with catch-rate and false-alert metrics pinned over the chart. Four modes: Tune the band, Review fired alerts (one click — valid or false alarm; a confirmed alert becomes ground truth), Label incidents (drag a span, lasso the anomaly cloud), and Autotune — the real search engine, run server-side on exactly the window you're looking at. Apply validates the config and writes it back into the metric YAML, archiving the previous version to metrics/.history/.

// recompute is client-side — the same detector math as the pipeline; no lock, nothing persists until Apply
// labels save to incidents/<metric>/ — the ground truth dtk autotune optimizes against, so a labeling round here feeds the next search

See the tuning cockpit guide →

The whole project on one screen.

dtk ui opens a localhost cockpit over the project: every metric's alert frequency and freshness at a glance (quality chips once incidents are labeled), the full HTML report one click away, run / autotune / tune driven as real dtk subprocesses — and a built-in editor to create, edit and delete metric YAMLs, validated before any write, previous versions archived to metrics/.history/.

Alerts that lead with the rule that fired.

Direction-aware multi-detector quorum, cooldown, recovery and no-data alerts — posted to chat with the alert and its rule up top, anomaly evidence below. A slow burn that never strings N anomalies in a row? An opt-in window-share rule (anomaly_window + min_anomaly_share) catches it without paging on every blip.

{"threshold": 3.0, "window_size": 2016, "half_life": "1d"}

alerting:
  channels: [mattermost_ops]
  dashboard_url: https://grafana.ops/d/api-errors   # one line → a link on every channel

Your warehouse runs the SQL. A free local DB keeps the state.

Warehouses punish frequent small writes — Snowflake bills a 60-second minimum every time it resumes; BigQuery a 10 MiB minimum per query. So detectkit runs a metric's load SQL on your warehouse, then keeps every _dtk_* table — detections, alert state, resume cursors — in a cheap local database. You monitor the warehouse without paying warehouse prices for the bookkeeping. Hybrid mode →

# metrics/revenue.yml — one line flips a metric into hybrid mode
source_profile: snowflake_prod   # load runs here; state stays on your --profile

What detectkit is — and isn't.

Deliberately narrow: statistical anomaly detection and alerting for business metrics you define in SQL. Here's how that differs from the neighbors — by scope and deployment, the things that actually vary.

Compared on scope + deployment only — never maturity, support or star counts. The OSS corner of this space is thin: most alternatives are either heavy platforms or unmaintained.