Data observability tools are built to watch freshness and schema. So when a stale table or a renamed column reaches a dashboard anyway, the monitor usually isn’t broken. It was pointed at the wrong question, at the wrong place, or it was switched off.
Five ways the monitor misses
| Why it misses | What happens | The fix |
|---|---|---|
| Freshness judged against the table’s own history | The load arrives at its usual time, after the report that needed it already ran | Test arrival against the downstream schedule |
| The monitor hasn’t learned the calendar | Alerts every Saturday and every month-end; the team mutes the channel | Let it learn seasonality before you trust it |
| The table isn’t monitored | Per-table pricing made someone choose; this one lost | Monitor every table, especially landing tables |
| The break happened before the warehouse | A vendor file changed layout; the monitor sees it only after the load | Profile the file where it lands |
| The failure is in a job, not a table | A job ran late or twice and the table still looks plausible | Watch the jobs, not only the tables |
On time by its own standard, late for everyone else
A freshness monitor learns when a table normally updates and flags a run that doesn’t fit. That catches a load that never came. It doesn’t catch a load that came at 4am every day for a report that runs at 3. Latency problems corrupt numbers without breaking pipelines, because pipeline success rates, data volumes, and schema compliance measure nothing about cross-system timing. The Guide to DataOps Tests puts it plainly: test arrival against the schedule the downstream consumers expect, not only against the previous run. Write the clock into the agreement: customer data by 2 AM Eastern, with every transaction processed by midnight in it.
The monitor nobody listens to
The math behind anomaly detection is a commodity. What decides whether a monitor stays on is the calendar. Volume drops on weekends. Claims spike at month-end. A detector that hasn’t learned your seasonality fires every Saturday and every close, and per the Guide, your team filters the channel inside a month. After that, the real freshness failure lands in a channel nobody reads.
Muted is the same as missing.
Let a monitor learn a column’s shape over 90 days, and prefer models that learn day-of-week patterns over fixed bands like the Guide to DataOps Tests example “sales should not vary more than 10% week over week.”
Coverage you rationed
Per-table pricing makes you pick which tables to watch, which forces teams to guess which ones matter. The schema change happens on the table you skipped. Pricing that doesn’t count tables is the cheap fix, and DataKitchen has a stake in saying so: TestGen Enterprise charges per user and per connection, not per table. Monitoring every landing table is the real fix.
The change came in through the side door
Schema monitors watch the warehouse. A lot of drift starts in files. In DataKitchen’s October 2026 TestGen release post, a healthcare team’s partner CSV files changed layout from one delivery to the next, before anything reached Azure SQL. DataOps TestGen 5.134.0 now profiles CSV, Parquet, and JSON files on a local path, in Amazon S3, or in Azure Blob Storage, so a new or renamed field shows up at the file, the day it lands.
Tables look fine while jobs fail
A green DAG looks identical whether the data is right or wrong. A job can run late, run twice, or skip, and the table it feeds still looks reasonable. Data can be perfectly valid and eight hours stale. Table monitors can’t see that, because they don’t see the tools. Process observability watches the jobs themselves.
One more limit, so it doesn’t surprise you. Schema monitors catch columns added, dropped, or retyped. A logic edit that keeps every column and changes what one of them means leaves the schema as it was, and leaves the lineage graph unchanged too. That one needs a test on the values.