Zero configuration
The AI agent looks across all your tables and decides which ones are worth custom checks.
Checks tailor made for your tables, completely bespoke.
A triage agent looks across every table you monitor and decides which deserve checks of their own. It reads schema and profile statistics, never your rows. Available on Pro and above.
Custom agentic checks tailored to your data
Sentry reads each table's schema and its first profile, then proposes tailored checks that catch issues other tools would miss — negative amounts, unknown status codes, orders pointing at customers that no longer exist.
orders · proposed plan
Status stays inside the four known states
status not in ('pending', 'paid', 'refunded', 'cancelled')
0 today·0 typical
CRITICALEvery order points at a customer that exists
orders.customer_id with no customers.id
400 today·12 typical
Delivery never precedes the order
delivered_at < created_at
0 today·0 typical
Updated every week
The agent revisits your tables and checks as your schema, findings and feedback change.
How it works
Every week, a triage agent looks across your monitored tables and decides which ones deserve custom agentic checks based on importance. A planning agent then defines the specific tests that run nightly in addition to the standard checks.
01
Triage
Decides which of your tables deserve checks of their own, and how many.
- What it reads
- Every monitored table, the priority you set, its columns and latest profile, the findings the standard checks raised over the last 30 days, and how its existing custom checks have fared, including any you muted or switched off.
- How it decides
- Your priority first, then what the table is and whether it has real daily volume. Orders and payments come ahead of staging copies, lookups and logs, and a critical table producing no findings may be the blind spot worth covering.
- The allowance
- Your plan sets one budget per kind of check, shared across the whole organization. Triage concentrates it on the tables that carry the business instead of spreading it thinly.
- When it runs
- The moment you pick tables, then once a week. It prefers leaving an allowance unchanged, so a settled organization is not re-planned for the sake of it.
02
Planning
Writes the specific checks for each table that was given an allowance.
- What it sees
- The table's schema and profile statistics, its monitored sibling tables, any feedback you have left, and triage's note on what is worth watching. The only values it sees are those of short, low-cardinality columns such as a status code; free text never reaches it and no row is ever sent.
- What it writes
- Metric expressions that run alongside the nightly standard checks. Aggregate SQL checks are a single-value query of their own, for questions that need a join or a filter, such as orders with no matching customer.
- Staying in budget
- It spends up to the table's allowance and no further. When triage cuts an allowance, the planner retires checks to fit, so budget moves between tables week by week.
- What it leaves alone
- Checks you have switched off. The planner can never re-enable or quietly re-create a check you disabled.
03
Validation
Proves every proposed check against your live warehouse before it is saved.
- Read-only, always
- No writes, no DDL, no temp tables. Every statement is checked before it runs and may reference only the target table and its monitored siblings.
- Proven on live data
- Each proposal runs once, with a 60-second limit, and must return exactly one row and one numeric column. A rejection goes back to the planner with its reason, so it can revise.
- Stable or rejected
- Metric expressions on a table with a timestamp column are replayed over the last 90 days. A check that would already be firing, or whose history swings too widely to score, is rejected, and near-duplicates of existing checks are dropped.
- Live from day one
- The replayed days are kept as the check's history, so a new check can flag on its first night instead of spending a week learning a baseline.
04
Nightly run
Scores each check against its own history, alongside the six standard checks.
- What it learns
- One number per check per day, and that series' average and spread. Twelve orphaned rows a day is the baseline; four hundred is the anomaly. Five days of history come before any flag.
- When it flags
- At three standard deviations from normal, or two plus a change of at least half. A metric that has never moved flags on a change of half, and one that has never been non-zero flags once it reaches three.
- What the agent does
- Nothing, until a day is flagged. Then the table's single agent session, shared with any standard check that flagged, queries the warehouse, cites the rows behind the number and decides whether it is worth reporting.
- What it leaves alone
- Days a check returns no number, which count as absent rather than zero. A check that fails to run, or points at a table you no longer monitor, is switched off with a reason instead of raising a false alarm.