Freshness Monitoring: By Hand vs With an AI Agent

Freshness monitoring by hand means an engineer writes a freshness rule per table, schedules it, and triages every alert. With an agent, the agent tracks each table against its SLA and alerts when data goes stale, while a human still owns the SLA and any fix. dbt's own source freshness guidance pairs a 1-hour SLA with a 30-minute check frequency, which shows how quickly manual coverage multiplies.

Key Takeaways

• •Freshness monitoring is a three-part job: define an SLA per table, check it on a schedule, and route alerts to someone who can act.
• •dbt's docs recommend running freshness checks at least twice as often as your lowest SLA, so a 1-hour SLA implies a check every 30 minutes.
• •Manual coverage breaks at scale because every new table needs its own rule, threshold, and owner, and nobody revisits them when usage changes.
• •The Quality Agent's freshness skill tracks table freshness against SLAs and alerts when data goes stale; it does not decide what the SLA should be.
• •Evaluate any agent on SLA coverage, alert precision, and whether it is read-only by default, not on demo dashboards.

The job and who does it today

Freshness monitoring answers one question: is the data in this table recent enough for the people and systems that depend on it? In most teams the answer lives in an analytics engineer's head, a dbt YAML file, or a Slack thread from the last time a dashboard went stale. The person who owns it is usually whoever got burned most recently.

The job has three distinct parts that often get blurred. First, someone decides the SLA: how stale is too stale for this table, given who reads it. Second, someone implements a check that measures staleness against that SLA on a schedule. Third, someone receives the alert and works out whether the cause is an upstream delay, a failed job, or a source that simply had nothing new.

Only the second part is mechanical. The first is a business decision and the third is investigation. Most of the pain in manual monitoring comes from treating all three as one chore for one engineer, so the mechanical work crowds out the judgment work.

The manual workflow, step by step

A typical manual setup in a dbt and warehouse stack has five steps. Each one has a tool and a handoff, and each handoff is a place where coverage quietly erodes.

• •Step 1, inventory: list the tables that matter, usually by asking stakeholders which dashboards break the business when they go stale.
• •Step 2, define SLAs: agree a threshold per table, such as one hour for an operational table or one day for a daily rollup.
• •Step 3, implement checks: add freshness configuration to dbt sources or write a scheduled query against a timestamp column.
• •Step 4, schedule and alert: run the checks in a job and send failures to a channel or pager.
• •Step 5, triage: someone reads the alert, opens the orchestrator, checks upstream jobs, and decides whether it is real.

The details matter in step 3. On Snowflake, the dbt docs note that freshness is calculated using the LAST_ALTERED column, which tells you when a table was last modified, not whether the business data inside it is recent. A table can be touched by a no-op merge and look fresh while its newest row is a day old.

Step 4 has its own trap. The same dbt page says dbt build does not include source freshness checks, so freshness only runs if you enable it as a job option or add dbt source freshness as an explicit run step. Teams that assume build covers it find out when a stale source gets through.

Where the manual workflow breaks

The first failure is coverage drift. Checks are written when a table is created or when it last caused an incident. Six months later the warehouse has new tables nobody wrote a rule for, and old rules still guard tables nobody reads. Nothing in the process tells you which is which.

The second failure is threshold drift. An SLA set when a pipeline ran hourly stays at one hour after the pipeline moves to daily, so the alert fires every morning and everyone learns to ignore it. Or the reverse: a pipeline gets faster, the SLA stays loose, and a real delay sits inside the threshold.

The third failure is the handoff at triage. The alert says a table is stale. It does not say which upstream job is late, whether a schema change caused it, or who consumes the table. The engineer becomes the integration layer between the warehouse, the orchestrator, and the catalog. That is the part that eats the time, and it is why detection alone rarely closes the gap.

Native warehouse features help with the first part but not the rest. Snowflake's data quality documentation says a data metric function schedule runs once every hour by default, and caps an account at 50,000 DMF associations on objects. Those are sensible defaults, but someone still has to choose which objects get associations and what happens when one fails.

What an agent does instead

The Quality Agent ships a skill called dw-freshness-monitoring, described as tracking table freshness against SLAs and alerting when data goes stale. That is the scope we claim: it takes the mechanical middle of the job, measuring freshness against the SLAs you have and raising an alert when a table crosses its threshold.

In practice that means you ask in your MCP client, for example Claude Code or Cursor, "Show freshness scores for all gold tables," and the agent reports each table against its SLA instead of you opening five tools. Because every Data Workers agent is an MCP server, the same capability is available to any MCP-compatible client without a new dashboard.

The swarm design matters at triage. The Quality Agent chains with the Incidents, Catalog, and Schema agents, so a stale-table alert can be correlated with a failed job or a schema change rather than arriving as an isolated message. We are careful about the claim: the freshness skill detects and alerts, and root-cause work belongs to the agents built for it.

What still needs a human approval

The agent should not set your SLAs. An SLA encodes how much staleness a consumer can tolerate, and that is a conversation between data owners and the people using the data. An agent can show you that a table has missed its threshold three times this month, but whether to loosen the threshold or fix the pipeline is a human call.

Writes also need approval. The open-source dw-claw edition is read-only by default, so it can measure and report but not change anything in your warehouse. Pro adds writes with approval workflows and audit trails, which means a change to a freshness rule or a pipeline fix is proposed, reviewed, and logged before it lands.

Escalation policy is the third human decision. Who gets paged for a stale finance table at 3 a.m. versus a stale experimentation table is organizational knowledge. The agent routes alerts to the owners you define; it does not invent an on-call rotation.

Manual vs agent: side-by-side

Honest framing: for a team with a dozen critical tables, dbt source freshness plus a good alert channel is enough and costs nothing extra. The agent earns its place when the number of tables, owners, and upstream dependencies outgrows what one person can keep in their head.

How to evaluate an agent for this job

Start with coverage. Give the agent your warehouse and ask which tables have no freshness SLA at all. A useful tool surfaces the gap you did not know about; a weak one only reports on rules you already wrote. Then compare its stale-table list against your last three incidents and check whether it would have flagged them before a stakeholder did.

Next, measure alert precision. Count how many alerts in a week were actionable versus noise. If the agent cannot tell a table that is late from a table whose source had no new data, you have replaced one noisy alert with another. Ask how it handles LAST_ALTERED-style false freshness, where a table was touched but holds no new rows.

Finally, check the safety posture. Confirm it is read-only by default, that writes require approval, that actions are logged in a tamper-evident audit trail, and that data stays in your infrastructure. A freshness tool reads metadata across your whole warehouse, so how it is permissioned matters as much as how well it detects.

Frequently Asked Questions

How often should freshness checks run?

The dbt source freshness guidance recommends running checks at least twice as often as your lowest SLA. Its examples map a 1-hour SLA to a 30-minute check, a 1-day SLA to 12 hours, and a 1-week SLA to roughly daily. The reasoning is simple: a check that runs once per SLA window can miss a breach by nearly a full window.

Does an AI agent replace dbt source freshness?

No. dbt source freshness is a solid, free baseline and the agent does not make it obsolete. The agent's freshness skill tracks table freshness against SLAs and alerts when data goes stale, and adds value on top by working across tools and tables. If you already run dbt freshness, treat the agent as a coverage and triage layer, not a replacement.

Can the agent fix a stale table on its own?

The freshness skill detects and alerts. Fixes involve changing pipelines, which is write access. The OSS edition is read-only by default, and Pro routes writes through approval workflows with audit trails. Whether a given fix is proposed or applied depends on how you configure approvals, and we recommend a human approve anything that touches production.

What is the difference between freshness and a data quality check?

Freshness asks whether data arrived on time. Quality checks ask whether the data that arrived is correct: nulls, duplicates, ranges, and distribution shifts. A table can be perfectly fresh and wrong. That is why freshness lives alongside the other checks in the Quality Agent, which wraps Great Expectations, dbt tests, and anomaly detection rather than treating freshness in isolation.