Freshness Check Examples¶

The situation: A CRM extract replaces customers_snapshot every four hours on Snowflake. A permissions change on the source makes the extract fail without an error on the warehouse side. The table keeps its old rows, so nothing looks wrong until a report shows stale customer data. The team allows two extra hours for late runs.

Check configuration

Payload

{
    "description": "customers_snapshot is refreshed at least every 6 hours.",
    "rule": "freshness",
    "fields": [],
    "container_id": 311,
    "filter": null,
    "properties": {"value": 21600000},
    "tags": ["crm", "sla"],
    "additional_metadata": {},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 18
}

A Scan with the Metadata category runs every hour, so the alert arrives within an hour of the table going stale.

Sample Data

What gets flagged

The 16:00 extract never lands. At 18:00 the table is still within its 6 hours, so the check passes. At 19:00 its last change is almost seven hours old, and the Scan reports a Shape Anomaly. Every hourly Scan after that reports the age again, until the next extract lands.

Flowchart

graph TD
    A["Scan reads when customers_snapshot last changed"] --> B["Age = Scan time - last modification"]
    B --> C{"Age within<br/>6 hours?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Report a Shape Anomaly"]

Equivalent SQL

-- On Snowflake, a table's last change comes from the platform's own record.
SELECT LAST_ALTERED
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'CRM' AND TABLE_NAME = 'CUSTOMERS_SNAPSHOT';

The situation: daily_revenue on PostgreSQL is rebuilt once a night, normally by 02:00 UTC, and the finance dashboard refreshes at 07:00. The team wants an alert before the dashboard refreshes if the load has not run. Its incremental field is loaded_at, with the Last Modified Incremental Strategy.

Check configuration

Payload

{
    "description": "daily_revenue is rebuilt at least once a day.",
    "rule": "freshness",
    "fields": [],
    "container_id": 402,
    "filter": null,
    "properties": {"value": 86400000},
    "tags": ["finance"],
    "additional_metadata": {},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": null
}

A Scan with the Metadata category runs every day at 06:00 UTC, an hour before the dashboard refreshes.

Sample Data

What gets flagged

Monday night's rebuild is delayed past the morning. On Tuesday at 06:00 the newest loaded_at is still Monday's, more than a day old, so the Scan reports a Shape Anomaly an hour before the dashboard would have shown stale numbers. On Wednesday the rebuild runs on time and the check passes again.

Scanning about four hours after the usual load keeps a normal day well under 1 day and puts a missed day well over it, so small delays in either the load or the Scan do not flip the result.

Flowchart

graph TD
    A["Scan reads the latest loaded_at"] --> B["Age = Scan time - latest loaded_at"]
    B --> C{"Age within<br/>1 day?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Report a Shape Anomaly"]

Equivalent SQL

-- Outside Snowflake, BigQuery, and Databricks, a table's last change is the newest incremental value.
SELECT MAX(loaded_at) FROM daily_revenue;

The situation: v_open_orders is a view over the order system. Views have no platform record of their last change, so the team sets updated_at as the view's incremental field with the Last Modified Incremental Strategy. Orders change all day, so the view should never go two hours without a newer updated_at.

Check configuration

Payload

{
    "description": "v_open_orders shows an order change at least every 2 hours.",
    "rule": "freshness",
    "fields": [],
    "container_id": 515,
    "filter": null,
    "properties": {"value": 7200000},
    "tags": ["orders"],
    "additional_metadata": {},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": null
}

Sample Data (Scan at 15:30 UTC)

What gets flagged

The newest updated_at is 13:18, so at 15:30 the view is 2 hours and 12 minutes old, past its 2 hours. The order service stopped writing after a deployment, and the Scan reports a Shape Anomaly. The highlighted value is the one the check reads: the latest updated_at, not any single row's problem.

Without an incremental field, the same check is Not Asserted on every Scan, because a view cannot report when it last changed.

Flowchart

graph TD
    A["Scan reads MAX(updated_at) of v_open_orders"] --> B["Age = Scan time - MAX(updated_at)"]
    B --> C{"Age within<br/>2 hours?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Report a Shape Anomaly"]

Equivalent SQL

SELECT MAX(updated_at) FROM v_open_orders;
-- Returns 2026-03-11 13:18.