Most teams get this decision backwards. They open the schema browser, see four hundred tables, and either tick everything — a wall of alerts nobody reads and a warehouse bill nobody budgeted for — or tick nothing, promise to come back to it, and find out about the broken pipeline when the head of sales asks why revenue halved on Tuesday.

The useful list is smaller than you think, and it is not visible from the schema. It comes from the other end: from what people actually do with the data.

Start from the outputs, not the tables

Do not begin with the warehouse. Begin with a list of the things in your organisation that are wrong-in-public if the data is wrong. For most small teams that is between four and ten items:

  • The revenue dashboard the exec team opens on Monday.
  • The board pack or investor update, assembled monthly from a handful of aggregates.
  • The ML feature table that feeds a model making live decisions.
  • The billing or usage export that determines what customers are charged.
  • The reverse-ETL sync that pushes attributes into the CRM or a marketing tool.
  • The one operational report a team runs its week from.

Write those down first. Then trace each one backwards: which tables does it read, and which do those read? Eight or nine outputs usually collapse onto a small overlapping set — often a dozen tables or fewer. That set is your candidate list. Everything else is, for monitoring purposes, scenery.

This ordering matters. Picking tables by importance-in-the-abstract gets you the big, famous, well-maintained ones. Picking them by consumer gets you the quiet aggregate that three dashboards depend on and nobody owns.

Prefer the last table before the consumer

When you walk upstream you will hit a choice: monitor the raw landing table where data arrives, or the modelled table the dashboard actually queries?

Monitor the one closest to the consumer. A few reasons:

  • It catches more classes of failure. A raw table can be perfectly fresh and complete while the transformation between it and the dashboard silently drops rows, fans out a join, or starts producing nulls in a column the model added last week. Watching the input tells you nothing about that.
  • Its shape is stable enough to baseline. Landing tables get constant schema drift, backfills and replays. That is normal for them and looks like an incident to anything watching. Modelled tables change on your release schedule.
  • It maps cleanly to a decision. “The table behind the revenue dashboard is stale” is actionable at 8am. “A staging table has an unusual row count” needs someone to work out whether it matters first.

One exception: if a single raw table is the sole entry point for a critical pipeline, monitor it too. Freshness failures surface earliest there, an hour before the modelled table would have told you. That is one extra table, not forty.

What to leave alone

Some categories are almost always a mistake to monitor:

  • Staging, scratch and tmp_ tables. They are intermediate by design. They get truncated, rebuilt, and left half-populated between steps. Every one of those is a finding you will have to dismiss.
  • Backups, snapshots and archives. A table that is deliberately frozen will trip freshness checks forever. A table that is appended once a quarter has no useful daily baseline.
  • PII-heavy tables you do not need to watch. Raw customer records, credentials, payment details. If the business logic is fully represented downstream, monitor the aggregate and never grant access to the source. A tool cannot leak what it was never shown.
  • Tables with no consumers. If you cannot name what reads it, nobody will act on a finding about it. Ask instead whether it should still exist.
  • Very low-volume dimension tables. A country lookup that changes twice a decade has no pattern to learn and no failure mode worth an email.

Assign priority tiers, and mean them

Sort the list into three tiers. A tier is not a label of how much you like the table — it is a statement about who gets interrupted.

  • Critical. Wrong data here has an external consequence: a customer is billed incorrectly, a model makes bad decisions, a number goes to the board. Look at these the morning they appear, before anything else. Keep the tier small — five or six tables for most teams. If a third of your list is Critical, none of it is.
  • Normal. Internal dashboards and reports where a day of wrongness is embarrassing but recoverable. Triage these in the same sitting, after the Critical ones. This is where most of your list belongs.
  • Low. Tables you want a record of but would not change your day for. Useful for context when investigating something else, and for spotting slow drift.

Tiers only work if they change behaviour. Write down, once, what each means in practice: who checks it, how fast, and what they do if it is still broken tomorrow. A tier that produces the same response as every other tier is decoration.

A 30-minute exercise you can run this week

Get the two or three people who know the pipelines round a whiteboard.

  1. Ten minutes. List every output that would embarrass someone if it were wrong. Dashboards, exports, syncs, reports. No warehouse, no schema — just consumers.
  2. Ten minutes. For each, name the tables it reads. Draw the arrows. Circle every table that has two or more arrows pointing at it; those are your load-bearing tables.
  3. Five minutes. Cross out staging, scratch, backup and PII-heavy tables. Cross out anything with no named consumer.
  4. Five minutes. Assign Critical / Normal / Low to what is left, and write next to each Critical table the name of the person who would fix it.

Whatever survives is your monitoring list. If it is longer than you expected, the exercise has told you something useful about your architecture.

To seed the whiteboard, pull the tables that are actually being read. In Postgres:

SELECT
  schemaname,
  relname AS table_name,
  n_live_tup AS approx_rows,
  seq_scan + idx_scan AS total_reads,
  last_autovacuum
FROM pg_stat_user_tables
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY total_reads DESC
LIMIT 40;

Every warehouse has an equivalent view of who reads what: Snowflake has SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY, BigQuery has INFORMATION_SCHEMA.JOBS, Redshift has its own query-history tables. The point is to walk in with evidence about which tables are genuinely hot rather than a memory of which felt important.

Revisit it quarterly

Monitoring lists rot in both directions. Pipelines get rebuilt, dashboards get retired, a new model starts depending on a table nobody was watching, and the table that was Critical last spring now feeds a report nobody has opened since.

Once a quarter, spend fifteen minutes on two questions: what has been added that a consumer now depends on, and what has been muted or dismissed so often that it should drop a tier or come off the list. Coverage that nobody prunes turns into noise, and noise is how monitoring stops being read.

How Sentry handles it

  • Monitoring is opt-in per table. You browse the schema and select what to watch. Anything you do not select is never queried, which keeps both the noise and the scan cost tied to the list you chose.
  • Every table gets a priority tier. Critical, Normal or Low, set when you add it. The tier weights the severity of any finding on that table, so the morning digest is ordered by what deserves your attention rather than by what happened to be checked first.
  • Baselines are learned per table. Sentry profiles each table’s own history — weekend dips, weekly load schedules — so a consistent-but-unusual rhythm is not a finding.
  • Noise control for the edge cases. Mark a pattern as expected to fold it into the baseline, or mute a single check on a single table for a set period. On the larger plans there is a per-table sensitivity dial.
  • Table counts vary by plan, which is a healthy constraint in practice: it pushes you to do the exercise above rather than tick everything. See pricing for the limits.

Start with the tables behind the outputs people act on. Add the rest when something surprises you.

Pick a plan and get started — read-only credentials, first digest tomorrow morning.