Question 1

How does freshness monitoring work?

Accepted Answer

You set an SLA per table (e.g., "must update every 6 hours"), and AnomalyArmor watches the max(updated_at) or equivalent column on a schedule. If the table misses the SLA, an alert fires with the last observed update time and the number of hours overdue.

Question 2

What if my table has no updated_at column?

Accepted Answer

AnomalyArmor falls back to table metadata (last modified time from INFORMATION_SCHEMA) or row count deltas. For append-only tables with neither a timestamp nor a meaningful count change, you can provide a custom SQL expression to derive freshness.

Question 3

Can the freshness SLA be learned automatically?

Accepted Answer

Yes. Point AnomalyArmor at a table and it analyzes the last 30 days of update cadence to propose an SLA. You can accept the suggestion or override it. Learned SLAs update on a 7-day rolling window, so a table whose cadence changes over time adapts automatically.

Question 4

How is this different from pipeline or orchestrator monitoring?

Accepted Answer

Orchestrator monitoring (Airflow, dbt Cloud) tells you the job ran. Freshness monitoring tells you the data landed. A job can succeed with zero rows written, a retry can double-insert, or the DAG can be paused entirely; freshness monitoring catches all three because it inspects the data, not the job.

Question 5

Does freshness monitoring work for streaming tables?

Accepted Answer

Yes, with a tighter SLA. Streaming tables (Kafka sinks, CDC replicas) are monitored with lag-style SLAs (e.g., "never more than 5 minutes behind"), and the alert includes a lag histogram for the last hour so you can see whether it is a one-off spike or sustained drift.

Freshness Monitoring

Never Miss a Data Delivery Again

Automatic Pattern Learning

SLA Tracking

Smart Anomaly Detection

Ready to monitor your data freshness?

Frequently Asked Questions