Crewdata On-Call

Data on-call, worked by agents. Signed by you.

When a dbt model or test fails, On-Call opens a case and routes it to the agent role that owns that kind of failure. It investigates in its own copy of your project, a second agent tries to refute the fix, and nothing reaches your repo until a named person signs.

Live

Join the first pilots How it works
  1. 06:12A data check fails. A case opens.
  2. 06:52Two agents find the cause, the source sent some orders twice, and write the fix.
  3. 07:04The reviewer tries to refute it in a separate copy of the project. It can’t. None of them is a person.
  4. 08:40A person signs. The fix goes to the repo.
An example case.
Why now
  1. 01First, alerts told you something broke.
  2. 02Then, channels got everyone in the room.
  3. 03Now, a crew works the case. You sign.
The cost

Incidents are eating your roadmap

A broken number costs the sprint someone dropped to chase it, and the dashboard your CEO stopped trusting.

What your rota costs you a year—
What wakes it

Failed dbt models and tests open cases

Add one line after your dbt command. With Elementary, anomalies, schema changes and source freshness open cases too.

dbt Core models and tests, on the same machineLive
Elementary anomalies, schema changes, source freshnessLive
dbt running elsewhere (dbt Cloud, hosted CI)Next
Alerts from Airflow, Dagster, Monte Carlo, Sifflet, SYNQ · DataformRoadmap
Warehouse: BigQueryLive
Warehouse: SnowflakeRoadmap
The crew

A case moves through a team, not one giant prompt.

Inside an investigation

What the agent actually does with your failure

What it gets

Written by code, before any AI runs
  • The failing test or model, and dbt’s error
  • The compiled SQL
  • The BigQuery job
  • Up to 5 sample rows. Never included if the column is tagged as personal data

What it does

Live
  • Reads the model and its YAML in its own copy of your dbt project
  • Runs dbt and queries BigQuery with the dev key you scope
  • Follows the model upstream and downstream
  • Writes down what broke, why, and what it ruled out
  • Commits a fix in a copy with no git remote and runs dbt build on it

The reviewer

Live
  • Gets the change applied to its own copy by code, not by the author
  • Re-runs dbt and tries to reproduce the failure
  • Tries to break the fix
  • Approves, or sends it back with what’s missing
In build

We grade the crew on failures we cause on purpose. Each broken case runs several times. Code, not the agent that wrote the fix, decides whether it worked: the broken test turns green, nothing that was green breaks, and no data or test was touched. We’ll publish the numbers when the first baseline is done.

One case, start to finish

Watch one case go through the crew

Duplicate ordersAn example case
  1. 06:12Signaldbt test: unique on stg_orders.order_id fails with 14 duplicates. A case opens; triage sends it to the delivery lead.
  2. 06:31Delivery leadReads the data, changes nothing. The 14 duplicates are orders that raw_orders received twice: same order_id, different load time. The source re-sent them after a retry. Hands it to the modeling specialist.
  3. 06:52Modeling specialistKeeps only the latest row per order_id in stg_orders. Commits it in its own copy and runs dbt build: green.
  4. 07:04ReviewerGets the change in a separate copy, applied by code. Reproduces the failure on the old model, then checks the fix: the test passes, the row count equals the distinct orders, downstream models still build. Can’t refute it. Approves.
  5. 08:40Person signsThe fix goes to the repo with the case and the signer in the commit.
The fix

Nothing reaches your repo until a named person signs.

Agents commit fixes in a working copy with no git remote. You sign on The Morning, the screen where everything waiting for your signature is collected: the case, who owns it, how long it has waited, and Sign, Send back, or Take it yourself.

The signed fix arrives as a pull request on a branch, with the case and the signer in the commit. Your branch protection, required checks and reviewers apply. The merge is yours.

You signBranch + pull requestYour required checksYour merge
Sign on The Morning, on the On-Call machineLive
Close the case only after dbt passes on the merged fixNext
Diagnosis, diff and the reviewer’s verdict on The Morning itselfNext
Sign from SlackNext
Microsoft TeamsRoadmap
Where autonomy stops

Code decides. Agents work. No room to take the irreversible step.

Agents can get things wrong. So whatever must happen every time is done by code, not left to a model.

Code does, every time
  • Sorts the failure and gathers the evidence before any AI runs
  • Applies the change to the reviewer’s copy
  • Enforces the clock, the spend cap and the signature
  • Writes the commit with the case and the signer
Agents do, on their own
  • Investigate
  • Query
  • Build in their own copy
  • Test
  • Challenge each other’s fixes
  • Send work back
Agents can’tenforced in code, not asked in a prompt
  • Write to your repo themselves
  • Sign
  • Skip the review step
  • Run past 50 minutes or the spend cap

Repository writes are done by code, only after a person signs.

Bounded by what you give them
  • Your warehouse: they read what their key can read. Scope it to a dev dataset and cap its bytes.
Guardrails

Six guardrails

/01Live

What the crew may do is set by the engine, not by a prompt.

Today, every fix needs a signature.

/02Live

Spending caps that pause the crew.

On estimated AI spend, per company and per agent.

/03Live

Every case has a clock.

After 50 minutes, agents stop and the case waits for a person.

/04Live

Repeated failures stay on one case.

/05Live

Recovered isn’t resolved.

If a failing test passes again before it’s fixed, the agents stop and the case goes to a person, with when it failed, when it passed and how many times. Nothing closes itself. For schema changes and anomalies a pass proves nothing, so the agents keep working.

/06Live

The right signer.

The dbt group’s owner, or your default signer.

A budget at 101% of its limit, marked paused.
A budget at its limit: work pauses. Spend is estimated. Our test installation.
Trust

Can it ship to production on its own? No.

Live

Can it change production by itself?

Production changes only through your git and your own deploy, after a named person signs. For your warehouse, the boundary is the key you give the agents (next question).

What access does it need?

A warehouse key for the agents. Scope it to a dev dataset and cap its bytes: that scope is the boundary.

What leaves your machine?

Calls to the AI model (with what agents read from your warehouse), warehouse queries, the branch and pull request to your git host, and first-install downloads. Containers aren’t network-isolated.

→ All seven questions, with their limits
Requirements

Works today if you have

Live
  • BigQuery
  • dbt Core 1.11 running on the same machine
  • Docker Compose 2.24 or newer, and Python 3
  • a git repository On-Call can open pull requests on
  • a machine that stays on
  • a Claude subscription for the agents

No observability vendor required. Today the service stops itself after 8 hours.

Next Unattended, continuous service.

Roadmap Alerts from the observability tool you already use, so you can switch without losing your on-call.

Missing one? Tell us.

FAQ

Questions buyers ask

Which dbt?

Tested with dbt Core 1.11 and Elementary 0.23.1. Older versions are next.

What if many models fail at once?

Five or more build errors in one run usually share one cause, like the warehouse, a quota or permissions. They make one outage case, for a person.

Where does it run?

On your machine, with Docker Compose. You sign from a browser on it.

Which git?

The signed fix arrives as a pull request on your repo. Your branch protection, required checks and reviewers apply, and the merge is yours. We never ask you to relax them.

Does it replace my data team?

No. It takes the first pass. Outages and unit-test failures go to a person.

How much does it cost?

Pricing isn’t set yet. Tell us about your stack.

Where this is going

On-Call is the first job of Crewdata’s AI data team: the one data engineers like least. The same organization of roles, review and signatures is built to take on more of the job next: quality, governance, catalog and analytics.

Early access

Join the first pilots

Tell us about your stack.

This opens your email app with your answers filled in. Nothing is stored on this site. Prefer plain email? hello@crewdata.ai

Your data will break. Have a crew ready.

Join the first pilots