Health checks

Verification says the organization stands behind a table’s definition. A health check says its data is still right.

Only the second one catches the failure that costs you a morning: the pipeline that quietly stopped delivering rows, the column that used to be complete and now isn’t, the export that truncated. The table still builds, its definition never moved, and every number read from it is wrong.

A health check is a named assertion about a table’s contents — “orders always have an id”, “this table has rows” — with a plain-language reason attached. Ronja re-checks it every time the table rebuilds, and tells you when the answer changes.

Where they come from

Ronja writes them, in Build mode. When she builds a table there, she adds one or two checks in the same turn — while she still has the context to know what “correct” looks like for that data — and says what she is asserting and why.

In a Build-mode chat you can also ask for one directly: “add a check that orders never has a null id”, or “warn me if this table stops refreshing daily”. She runs it there and then and tells you whether it holds, so you find out immediately if the assertion is already false. Writing and editing checks is Build mode only.

Checks are written in chat, not on the table page. What the table page owns is the decision you make under pressure: turning a noisy one off.

Two kinds

An assertion about the contents — anything true or false about the data itself: a column that is never empty, a count above zero, a value that stays in range. It runs whenever the table rebuilds.
A freshness check — “this table should refresh every day.” It catches the table that stops rebuilding altogether, which no other check can: a check that only runs on a rebuild can never fire on a table that has stopped having them. Ronja re-checks it in the background whether or not the table builds, and allows some slack before flagging it so an ordinary late run doesn’t cry wolf.

A freshness check also sets the table’s window on the Data map: the Freshness lens judges the table by the interval it declares rather than by the 30-day rule, and turns it red at the moment the check would flag it.

A table that is never meant to refresh — a list of codes, a calendar, a lookup written once — can be marked never stale instead: ask Ronja to mark it, or set it over the API. The Data map then never calls it stale, and its freshness check is silenced; only an admin can mark a table whose freshness check is Admin-protected. A table marked never stale can’t have an active freshness check until it’s unmarked.

A table can carry up to 20 active content checks, and one active freshness check. A freshness check’s interval can be anything from 5 minutes to 90 days. Silenced checks do not count against either — silencing one frees its slot.

Reading them

Open a table and go to the Checks tab. Each check shows what it asserts, the reason it was written, whether it is currently passing, and what was last observed.

Every table with an active check carries a small status marker — in the feature’s table list and at the top of the table page — so you can see where a table stands without opening anything. It reads Checks passing when every check passes, and otherwise says Not yet evaluated, Couldn’t be evaluated, or how many checks are failing. A table with no checks, or one whose checks are all silenced, carries no marker at all.

If something is failing, a banner at the top of the table page also says how many checks are failing and when that started — the moment a check went from healthy to failing, not the last time it ran.

The side panel that opens when you click a table in an exploration shows the same marker, and — when the table carries a check — a Checks tab beside Data and Schema, so you can read and silence checks without leaving the conversation.

State	What it means
Passing	The assertion held the last time it ran.
Failing	The assertion did not hold. The data is not what someone said it should be.
Couldn’t be evaluated	The check itself broke — usually because a column it names was renamed or dropped. This says nothing about whether your data is right.
Not yet evaluated	The check exists but hasn’t run yet. It runs the next time the table rebuilds — or, for a freshness check, at the next background re-check.
Silenced	Somebody turned it off. It doesn’t run and doesn’t count toward the table’s state.

“Couldn’t be evaluated” is not “failing”, and Ronja keeps them apart deliberately: nobody should be told their data is wrong because the checker broke.

A failing check never blocks anything

The table stays queryable, its builds keep running, and nothing downstream is stopped. A health check is advice, not a gate.

What it does do is make the answer honest. When Ronja reads from a table whose checks are failing, she says so and names what is failing, so you can judge the number rather than take it on trust.

Who hears about a failure

Every check tells the organization’s admins when it starts failing in the background — when the table rebuilds, or at the next background re-check for a freshness check. There is no such thing as a check that fails quietly.

The alert goes out on whichever channels an Admin configured for it on the Notification routing page: email, a Slack message, or both. An organization that routes this alert to Slack alone gets it there and never by email.

It is sent when a check starts failing, not once per run: a check that keeps failing hour after hour is one alert, not thirteen. And at most once a day per check — if the same check recovers and breaks again later the same day, that is not a second alert.

A verdict produced in a chat — when Ronja writes the check or rewrites what it asserts — is reported to you in the chat instead: you are reading the answer as she gives it, and the admins do not need a copy. So a check that is already failing the moment she writes it is reported the first time it goes from healthy to failing afterwards. Renaming a check, rewording its description or bringing one back from silenced does not re-run it at all, and so can never stand in for that alert.

Whether a check is Admin-protected decides who may turn it off:

Anyone with edit access can silence — the default. Anyone who can edit the table can add one of these, and anyone who can edit the table can switch it off again.
Admin-protected — only an Admin can create it, silence it, or downgrade it to the first kind. An alert anyone could switch off would not be much of an alert.

You can get a second alert about the same table. If a check recovers and then breaks again on a later day, that is a new problem and a new alert. You will also get one if the check itself couldn’t be evaluated for a while and then failed again — the checker broke in the middle, the problem never went away. Every alert says how long the check has been failing, so a second one about a problem that never cleared still shows the original start.

The alert is off until an Admin switches it on. Unlike a failing automation, Table health check failed starts disabled: an Admin turns it on, and chooses who receives it and on which channels, under Notification routing in the admin area, in the Verification group — verification and health checks are the two halves of the same trust question, so they sit together. The same page is where you turn it back off if it gets noisy. Once it is on, each delivered email also appears under Notifications — the bell in the sidebar — for every recipient who is a person in your organization.

A second alert shares the group. Table column type widened sits beside this one under Verification, and fires when a column on a table Ronja writes to directly changes in a way that alters what an existing query returns — a column becoming text, a true/false column becoming numeric, or a new column appearing. Unlike this one it is on from the start: until an Admin routes it, it reaches the table’s owner, or your Admins when the table has no owner. See When a column changes type.

Silencing a check

A check that is right but that you can’t act on today is worth turning off rather than ignoring, so the ones left on still mean something.

Open the table and go to the Checks tab.
Click Silence on the check.

It stops running and stops counting toward the table’s state. Un-silence brings it back: that clears the check’s recorded history and starts it fresh from its next run — the table’s next rebuild, or the next background re-check for a freshness check — so a check you silenced for a month doesn’t come back reporting a month-long failure. It is not re-checked at the moment you bring it back, so it reads Not yet evaluated until that run; if it fails then, the admins hear about it.

To change what a check asserts rather than turn it off, ask Ronja in a Build-mode chat: “that check is too strict — allow nulls before 2024”. She rewrites it and runs it again so you can see the new answer.