Scherlok README
The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Scherlok listing page.
Scherlok
Your data broke in production. Again.
Scherlok makes sure it doesn't happen next time.
Zero config. Zero YAML. Zero rules to write.
Scherlok learns what "normal" looks like, then tells you when something changes.
The Problem
Every data team has the same nightmare:
A source API silently changes from dollars to cents. Revenue dashboards show wrong numbers for 3 weeks before anyone notices.
A column starts returning NULLs. A table stops updating. Row counts drop 40% on a Tuesday. Nobody knows until the CEO asks why the report looks weird.
Current tools (Great Expectations, Soda, dbt tests) require you to define what "correct" looks like before you can detect what's wrong. Hundreds of rules. Dozens of YAML files. And you still miss things — because you can't write rules for problems you haven't imagined yet.
The Solution
Scherlok takes the opposite approach: learn first, then detect.
Three commands. Five minutes. Done.
After five valid profiles, Scherlok learns per-metric variability from the latest 30 profiles using robust historical baselines for volume, numeric mean shifts, NULL rates, and distinct counts. During cold start or when history is not usable, it keeps the conservative fixed defaults.
What It Catches
| Anomaly | What Happened | Severity |
|---|---|---|
| Volume drop | Row count dropped 40% overnight | CRITICAL |
| Volume spike | 3x more rows than normal | WARNING |
| Freshness alert | Table hasn't updated in 12h (normally every 2h) | CRITICAL |
| Schema drift | Column removed or type changed | CRITICAL |
| NULL surge | NULL rate jumped from 2% to 45% | WARNING |
| Distribution shift | Column mean shifted 3+ standard deviations (Shewhart-style control limit) | INFO, WARNING above 5σ |
| Cardinality explosion | Status column went from 5 values to 500 | CRITICAL |
Every anomaly is auto-scored: INFO, WARNING, or CRITICAL. No thresholds to configure.
Works with dbt
Already running dbt? Scherlok complements dbt test with automatic anomaly detection — no rules to write.
Scherlok reads target/manifest.json, discovers every materialized model (table, incremental, view), auto-resolves the connection from your profiles.yml, and profiles each model:
Use it as a CI gate after dbt run:
Or collapse both steps into one with the wrapper:
The wrapper runs dbt run by default and uses the successful model nodes recorded in
target/run_results.json, so partial runs profile only what dbt actually built. Use
--build to run dbt build; successful models are still profiled when a test failure
causes downstream models to be skipped on dbt's handled failure path (exit 1), while
the wrapper preserves dbt build's exit code. Unhandled failures fail fast without
reading the artifact.
Both dbt and dbt-run-and-watch accept --output json for CI parsers — a single JSON document on stdout, nothing else.
Supported adapters: postgres, bigquery, snowflake, mysql, duckdb. For others, pass --connection-string explicitly.
📖 Full docs: dbt integration guide →
dbt Package — native tests
Prefer staying inside dbt? Install Scherlok as a dbt package for native data quality tests — no Python CLI needed.
Tier 1 — Instant (no setup): not_null_proportion, row_count_between, recency, unique_proportion
Tier 2 — Auto-learning (Shewhart control limits): volume_anomaly, null_anomaly — require the scherlok_metrics model to build baseline history.
📖 Full docs: dbt package README →
HTML dashboard
One self-contained HTML file (~28 KB): KPIs, per-table incidents grouped with first-seen timestamps, +/−/~ schema-drift diff, sparklines, and full anomaly history. Auto dark/light theme via prefers-color-scheme.
📖 Full docs: dashboard guide →
Use it from an AI agent (MCP)
Let Claude Code / Claude Desktop run data-quality checks directly:
The agent gets list_tables, investigate, watch, status, history, and check as tools. Credentials are resolved server-side (never passed by the model), every operation is read-only on the warehouse, and there's no arbitrary-SQL tool.
📖 Full docs: MCP server guide →
AI-explained alerts (--explain)
Your alert says what broke. --explain adds why — and what to check next.
When anomalies fire, Scherlok makes one Claude call for the whole batch and injects a short root-cause hypothesis into the same Slack/Discord/Teams/email/JSON alert:
Works on watch, ci, check, dbt, and dbt-run-and-watch. On dbt projects the hypothesis is lineage-aware: upstream parents from manifest.json go into the prompt, so cascading failures get traced to the source model instead of alerting on every downstream symptom.
- What it costs — one call per fired run (not per anomaly), Claude Haiku 4.5 by default: well under a cent per run (~$0.003). Override the model with
SCHERLOK_EXPLAIN_MODEL. Runs with zero anomalies make no API call. - What it sends — aggregates only: the anomaly type/severity/message strings already in your alert, dbt model names, detection timestamps. Never warehouse rows, cell values, or credentials — the test suite pins this as a contract.
- How to turn it off — it's opt-in; don't pass
--explain. If the API call fails (no key, timeout, rate limit), the original alert is delivered unchanged with a one-line note. Alerting never blocks on the LLM.
📖 Full docs: explainer guide →
How It Works
1. investigate — Learn the patterns
Scherlok profiles every table: row counts, column types, NULL rates, value distributions, freshness cadence, cardinality. Stores everything locally in SQLite.
2. watch — Detect anomalies
3. Alert — Slack, CI/CD, or both
Auto-detects Slack, Discord, and Teams from the URL and formats the payload accordingly. Any other URL receives a generic JSON payload.
CI/CD Integration
Use Scherlok as a data quality gate. The ci command does it in one line:
If Scherlok detects a critical anomaly, the pipeline fails. Bad data never reaches production.
Email alerts
Connectors
| Database | Status |
|---|---|
| PostgreSQL | Available |
| BigQuery | Available |
| Snowflake | Available |
| MySQL | Available |
| DuckDB | Available |
Remote Storage
Share profiles across CI runs and team members:
Why Not [Other Tool]?
| Great Expectations | Soda | Monte Carlo | Scherlok | |
|---|---|---|---|---|
| Setup time | Hours | 30 min | Weeks | 5 minutes |
| Config required | Hundreds of rules | YAML checks | Dashboard setup | None |
| Anomaly detection | Manual thresholds | Paid feature | Yes | Yes, free |
| Self-hosted | Yes | Limited | No (SaaS) | Yes |
| CI/CD gate | Yes | Yes | No | Yes |
| Price | Free | Freemium | $50-200K/yr | Free, forever |
CLI Reference
Install
Requires Python 3.10+.
Run via Docker
A pre-built image with every warehouse extra (dbt, bigquery, snowflake) is published to GitHub Container Registry on every release tag:
Mount your project directory and inject connection details the same way your CI does it; the entrypoint is the scherlok CLI:
The image is built from python:3.12-slim and runs unprivileged (USER scherlok).
Contributing
Contributions welcome! See CONTRIBUTING.md.
We're especially looking for:
- New database connectors (e.g. Databricks — see #37)
- Anomaly detection improvements
- Documentation and examples
License
MIT — Developed by Robson Bayer Müller