How it works

From connection to first alert in twelve minutes.

Driftline is not a test suite you have to write. It reads what your data has always done, and tells you when it stops doing it.

The pipeline
01

Connect

You issue Driftline a read-only role in your warehouse, or point it at a topic and a schema registry. It introspects the catalogue and lists every table, stream and feature view it can see. You choose what to watch.

read-only roleyour credentialsrevocable
02

Profile

For each column Driftline computes a sketch — histogram, distinct-count estimate, null fraction, min and max, arrival timestamp. Sketches are computed inside your compute and only the summary leaves. A billion rows becomes a few kilobytes.

HLL sketchest-digestno row values
03

Baseline

Fourteen days of sketches become the baseline: the shape this column holds when nothing is wrong. Day-of-week seasonality is modelled separately, so Monday is compared to Mondays. The baseline rolls forward as your data legitimately evolves.

14-day windowseasonality-awarerolling
04

Score

Every run is scored against the baseline on twelve signals, per column and per segment. Scores are calibrated so that a 0.6 in one column means the same as a 0.6 in another — you set one threshold, not four hundred.

PSIKL divergencecalibrated 0–1
05

Route

What breached goes to the team that owns the table, with the column, the segment, the run id, the commit range, and the before-and-after distribution attached. Everything else stays quiet. Alerts you dismiss twice stop arriving.

slackpagerdutywebhooklearns from dismissals
Data boundary

What leaves your account, and what never does.

Leaves your account

  • Column names and types
  • Histogram buckets and their counts
  • Distinct-count estimates, null fractions
  • Numeric minimums and maximums
  • Run identifiers and timestamps

Never leaves your account

  • Row values, of any column, ever
  • Free-text and blob contents
  • Primary keys and identifiers
  • Query results
  • Anything you have not selected to watch

On the Scale plan, nothing leaves at all: the scoring engine runs inside your own VPC and only alerts cross the boundary.

Typical timings

Where the twelve minutes go.

StageTypicalRuns
Grant the role, connect the source2 minonce
Catalogue introspection40 sdaily
Backfill 14 days of sketches8 minonce
Score a run (per 100 columns)1.2 severy run
Alert delivery after breach< 30 son breach
Questions

Reasonable objections.

Isn't this just anomaly detection with extra steps?

Anomaly detection watches metrics. Driftline watches distributions. A row count can be perfectly normal while the composition behind it has completely changed — that is the failure mode that survives every dashboard you already have.

We already have data tests. Why add this?

Tests encode what you thought to check. Driftline reports what actually changed. They catch different things: in our own numbers, 61% of drift incidents passed every existing test at the moment they were introduced.

Keep your tests. Driftline covers the columns nobody wrote a test for.

How do you avoid drowning us in alerts?

Three ways. Scores are calibrated across columns so one threshold works everywhere. Seasonality is modelled, so Monday spikes don't page anyone. And an alert you dismiss twice stops arriving — the dismissal is the signal.

What if our data is legitimately supposed to change?

Most of it is. The baseline rolls forward, so gradual, legitimate evolution is absorbed. Driftline flags the step change, not the trend. You can also mark a change as expected and re-baseline from that run.

Can it run entirely inside our infrastructure?

On the Scale plan, yes. The scoring engine deploys into your VPC and only alert payloads cross the boundary. The control plane never sees a sketch.

See it against your own history.

Connect one pipeline. Driftline backfills fourteen days and shows you the drift you already shipped.