Data
The null rate tripled in March and the board slide was already wrong
Row counts, null rates, orphans and freshness, checked every morning. Silence means clean.
What the worker does
Daily data quality monitoring by an AI worker means the checks actually run. Each morning the worker executes the checks written in its skill file against the Supabase connection: row counts against yesterday, null rates on critical columns, orphaned foreign keys, and the age of the newest row in each table. It posts a delivery comment only when a threshold trips. A clean run reports nothing.
- Runs
- Every morning
- Connections
- Supabase, Slack
- Clean run output
- Nothing
Data quality problems are found by accident
Somebody notices a number looks small. They check, and the ingestion for one source has been failing since a schema change three weeks ago. Every dashboard built on that table has been quietly wrong, including the one used in the board meeting, and nobody can say for how long without going back through the data.
The check that would have caught it on day one takes about four lines to describe. It does not exist because writing monitoring is never this week's priority, and because a check that nobody has to maintain is not a thing that exists.
The four checks worth having first
Each one catches a different failure mode, and all four fit in a skill file.
| Check | What it catches | What trips it |
|---|---|---|
| Row count against yesterday | Ingestion that stopped or doubled | A change outside the band you set |
| Null rate per critical column | A field that silently stopped populating | Null share above your threshold |
| Orphaned foreign keys | Rows referencing records that do not exist | Any count above zero, usually |
| Freshness of the newest row | A pipeline that runs but writes nothing | Newest row older than the expected interval |
Setting it up
This is the job most data teams put on the roster first.
- 1
List the tables that matter
Not every table. The ten that dashboards and billing depend on, because a monitor that alerts on unimportant tables gets muted within a fortnight.
- 2
Write the thresholds down
In the worker's SKILL.md: the acceptable day-over-day band per table, the null ceiling per column, the expected freshness interval. These are yours and you edit them directly.
- 3
Authorise Supabase
One click from the connections catalog. Credentials are verified at connect time and stored server-side, so the worker uses them and browsers cannot read them back.
- 4
State that silence is success
Write it into the acceptance criteria: a clean run reports no exceptions and closes. Otherwise you get a daily comment saying everything is fine, which trains everyone to stop reading.
- 5
Escalate through Slack
Add the Slack connection so a tripped threshold reaches the channel, while the full detail stays as the delivery comment on the task.
What this is not
Not a replacement for tests in the pipeline
Checks that run inside your transformation layer catch problems before the data is written. This catches what gets through, which is a different and complementary position.
Not anomaly detection
It compares against thresholds you wrote, not against a learned baseline. That makes it predictable and explainable, and it means it will miss things you did not think to check.
Questions people ask
+Does the worker need write access to the database?
No. All four checks are reads. Teams usually give the worker a read path through the Supabase connection and keep anything that writes behind human approval, which is how every data job on this site is briefed.
+What happens when a check trips at 6am?
A cloud machine runs the job on schedule regardless of whether anyone is online, and the delivery comment lands on the task. With the Slack connection authorised, the exception also reaches the channel where the on-call analyst will see it.
+How do I stop it alerting on known problems?
Write the exception into the skill file with the reason and, ideally, a date to revisit. Keeping known-issue exclusions in a file you can read is better than a mental list, because the file survives the person who made the exception.
+Can it check tables outside Supabase?
The connection catalog is fixed, and Supabase is the database connection in it. Stripe is available separately, which covers a common source of billing-side reconciliation checks.
Related
One analyst, thirty requests, and an AI worker in between
Five jobs that stand between a data team and the analysis they were hired to do.
The Monday metrics email that somebody writes on Sunday night
The numbers pulled and the paragraph written, delivered as a file rather than a link.
The incident ended and the writeup never started
The timeline assembled from the channel and the deploy history, with the gaps left honest.
Connect Supabase to Polaris
Supabase is the connection where a careless key choice does the most damage, and the only one Polaris cannot yet check for you.
Connect Slack to Polaris
Six scopes, no access to direct messages, and a bot that only reads the channels somebody invited it into.
Hire an AI data analyst
It settles what active user means, writes the query that matches the definition, and turns the numbers you hand it into a paragraph an executive can read.
Work log
The record that makes an unwatched run reviewable afterwards.