If you are the whole data team, your constraint is not skill. It is that every hour spent on data quality is an hour not spent on the request queue, and nobody notices until something is already wrong.

So the goal is not coverage. It is an operating model that survives a busy week: detection runs without you, judgement stays with you, and what you have decided not to do is decided on purpose rather than by exhaustion.

Pick the tables that would cause a phone call

The instinct is to start with the tables you know are fragile. Start instead with the ones where being wrong is expensive. For each table someone outside the data team depends on, ask: if this were silently wrong for three days, who finds out, and what do they do? If the honest answer is “nobody”, it does not go on the list yet. For most small teams that lands between five and fifteen tables, clustered in three places:

  • The tables behind numbers leadership repeats out loud. Revenue, active accounts, pipeline. These get quoted in board decks, so an error leaves the building before you hear about it.
  • The tables that feed something operational. A billing job, a customer-facing usage figure, a churn model that emails people. Wrong data here does something rather than merely displaying something.
  • The joins everything else is built on. Your dimension tables. One duplicated key quietly inflates a dozen downstream metrics at once, which is why fanout bugs get found by their symptoms.

Everything else waits. A short list you trust beats a long one you stop reading.

One check-in, at the same time, every morning

The failure mode for a one-person team is not missing a check. It is checking constantly and at random — a glance between meetings, a half-remembered “that looked odd yesterday”. Expensive attention that compounds into nothing. Replace it with one fixed habit: ten minutes, first thing, before the request queue opens. One place to look, one pass, three outcomes.

  1. Nothing to see. Close it. This is the common case and should take under a minute.
  2. Something is off, but small. Note it, timebox it, move on. Not every anomaly is worth today.
  3. Something is off and it feeds a number people act on. It becomes your first task — and you tell the stakeholder before they ask.

That last point is most of the value. What separates a trusted data team from an untrusted one is rarely accuracy; it is who spoke first.

Write down what “normal” looks like, once

The most wasteful thing a solo data person does is re-derive context they already had: forty minutes establishing that this table always dips at weekends, then the same forty minutes again in four months. Keep a plain file per critical table:

  • Load schedule. When it lands, from where, and what a normal delay looks like. “Usually 03:10, sometimes 05:00 on Mondays” saves ten minutes later.
  • Expected volume. Rough daily row count plus the known shapes: weekend dips, month-end spikes, the campaign that triples signups.
  • Known-weird columns. The one legitimately 40% null because it only applies to enterprise accounts. Write it down or re-investigate it forever.
  • Uniqueness assumptions. Which columns are meant to be unique, and what grain a row represents. This breaks most often and is hardest to reconstruct under pressure.

Cheap way to seed it — run this once per table and paste the output in:

SELECT
  date_trunc('day', created_at) AS day,
  count(*)                      AS row_count,
  count(DISTINCT order_id)      AS distinct_keys,
  avg((email IS NULL)::int)     AS null_email_rate
FROM analytics.orders
WHERE created_at >= now() - interval '90 days'
GROUP BY 1
ORDER BY 1 DESC;

Ninety days of that gives you load rhythm, duplicate history and null baseline in one pass.

The same file is your handover document. Three more entries and a second hire or your holiday cover can take the seat: who to tell for each table and how fast; the last three incidents, a paragraph each — symptom, cause, fix — because breakages repeat; and what is deliberately not monitored, and why, or your successor will start by adding coverage everywhere.

Make findings verifiable, so you can hand them over

When you are the only person who understands the pipeline, every question routes to you — including ones you should not answer live. Someone pings “is this number right?” and you are debugging in a chat thread while five people watch. Make anything you raise verifiable without you in the room. A finding should arrive with:

  1. What is wrong, in one sentence a non-technical stakeholder can repeat.
  2. The evidence — the query, a handful of offending rows, and what the number normally looks like.
  3. The blast radius — which reports are affected, and which are fine.
  4. What you are doing, and when you will next update.

Five extra minutes; saves an afternoon. A stakeholder with all four decides for themselves, without a round trip through you.

Refuse to be the alerting system

Above all, avoid being the mechanism by which the organisation finds out data is broken. If the only detector is you noticing, your holiday, your focus time and your sick days are all outages.

  • Detection is automated or it does not exist. A check that depends on you remembering to look is not a check.
  • Judgement is never automated. Whether an anomaly matters, what caused it, and who needs to know needs context that lives in your head and in the business. Do not encode it.

Machines detect, humans decide. Everything on the wrong side of that line is either a missed incident or an alarm you learn to ignore.

What a hand-built test suite costs one person

The standard advice is to write assertions: row counts, not-null constraints, uniqueness tests, freshness thresholds. For a handful of tables and a team with spare capacity, this works. For one person across a few dozen tables, here is what breaks, roughly in order:

  • Thresholds go stale. You set “at least 8,000 rows a day” in March. The business grows, a campaign lands, and by August it fires on healthy days. Every static threshold is unscheduled maintenance work.
  • The suite gets noisy, then muted. Once a fixed rule cries wolf on legitimate seasonality a few times, you stop reading it. A muted suite is worse than none, because it feels like coverage.
  • Coverage stalls at whatever you wrote first. New tables ship untested, because writing tests never wins against the request queue. Six months on, your monitoring reflects last year’s data model.
  • Nobody else can safely change it. Hand-built assertions encode assumptions nobody wrote down. Your cover cannot tell a deliberate threshold from a guess, so they change nothing and mute everything.

This does not make tests wrong. It means hand-maintained static rules do not scale past the number of tables one person can hold in their head. Keep them for bespoke logic that needs an exact assertion; let something else answer whether a table behaved the way it normally does.

How Sentry handles it

Sentry is built for exactly this shape of team: business-critical tables, no dedicated data-quality function.

  • Detection runs without you. Connect with read-only credentials you create, pick the tables that matter, give each a priority tier. Six check agents — freshness, volume, out-of-range, null-rate, format, duplicates — run nightly, after your data finishes loading.
  • You never write or maintain a threshold. Sentry profiles each table’s history to learn its own rhythms, weekend dips and weekly load schedules included, so “normal” is derived rather than declared, and does not go stale as the business grows.
  • One email, one morning. What was scanned, what is healthy, findings ordered by severity. Your ten-minute check-in, already assembled.
  • Findings are handover-ready. Each carries a severity, a plain-English diagnosis, and evidence: the queries run, sample offending values, the baseline it was judged against. Enough to forward to a stakeholder instead of debugging live.
  • Judgement stays yours. Sentry diagnoses and never writes to your warehouse: no fixes, no remediations. Resolve a finding, mute it, or mark it expected to teach the baseline.

It will not replace the parts of the job that need you. It stops you being the thing that has to notice. Table limits and plans are on the pricing page.

Want it watching your own tables? Pick a plan and get started — read-only credentials, first digest tomorrow morning.