Metric Check Examples¶

The situation: Finance tracks yesterday's revenue. A Computed Table named daily_revenue aggregates ORDERS into one row:

SELECT SUM(o_totalprice) AS revenue
FROM orders
WHERE o_orderdate = current_date() - 1

Revenue normally moves a few percent from one day to the next. The team wants an alert when it moves by more than 30% in either direction. A Full Scan runs every morning at 06:00 UTC.

Check configuration

Payload

{
    "description": "Yesterday's revenue stays within 30% of the previous day's.",
    "rule": "metric",
    "fields": ["revenue"],
    "container_id": 640,
    "filter": null,
    "properties": {"comparison": "Percentage Change", "min": -0.3, "max": 0.3},
    "tags": ["finance"],
    "additional_metadata": {},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 21
}

Sample Data

What gets flagged

On Wednesday half of the order feed arrived late, so the computed table's total fell by more than half. The drop breaks the -30% floor and the Scan reports a Record Anomaly on the computed row. On Thursday the check compares with Wednesday's 610,400.50, so a recovery to normal levels shows as a large increase too. Acknowledge the pair when you triage it.

Flowchart

graph TD
    A["Full Scan reads the one row of daily_revenue"] --> B["Record the revenue measurement"]
    B --> C{"Within -30% and +30% of the<br/>previous Full Scan's measurement?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Report a Record Anomaly"]

The situation: region_kpis holds one row per sales region with that region's current conversion_rate. The EMEA team expects a rate between 2% and 8%. The filter clause narrows the table to the EMEA row.

Check configuration

Payload

{
    "description": "EMEA conversion rate stays between 2% and 8%.",
    "rule": "metric",
    "fields": ["conversion_rate"],
    "container_id": 655,
    "filter": "region = 'EMEA'",
    "properties": {"comparison": "Absolute Value", "min": 0.02, "max": 0.08},
    "tags": ["sales", "emea"],
    "additional_metadata": {},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": null
}

Sample Data

What gets flagged

The filter leaves only the EMEA row, so the check has exactly one value to measure: 0.012, below the 0.02 floor. A broken tracking tag on the EMEA storefront stopped recording orders. The Scan reports a Record Anomaly on the EMEA row, and the NAMER and LATAM rows play no part.

Without the filter, the three rows would make the check Not Asserted on every Scan. A check per region, each with its own filter, can coexist on the same field.

Flowchart

graph TD
    A["Scan reads region_kpis"] --> B["Keep rows where region = 'EMEA'"]
    B --> C{"Exactly one row?"}
    C -->|No| N["Check is Not Asserted"]
    C -->|Yes| D{"conversion_rate between<br/>0.02 and 0.08?"}
    D -->|Yes| E["Check passes"]
    D -->|No| F["Report a Record Anomaly"]

Equivalent SQL

SELECT conversion_rate
FROM region_kpis
WHERE region = 'EMEA';
-- Returns 0.012.

The situation: treasury_position holds a single row with the company's cash_balance, updated by the treasury system. The balance drifts every day, but a movement of more than 500,000 between Full Scans needs review.

Check configuration

Payload

{
    "description": "The cash balance moves by at most 500,000 between Full Scans.",
    "rule": "metric",
    "fields": ["cash_balance"],
    "container_id": 702,
    "filter": null,
    "properties": {"comparison": "Absolute Change", "min": -500000, "max": 500000},
    "tags": ["treasury"],
    "additional_metadata": {},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": null
}

Sample Data

What gets flagged

Full Scan #1 has no previous measurement, so it only records 12,400,000. Scan #2 moves 250,000, inside the limits. Scan #3 moves 1,330,000 because a transfer was booked twice, past the +500,000 bound, and the Scan reports a Record Anomaly.

If the same check also ran on Incremental Scans, those would keep a separate history and start with a recording-only Scan of their own.

Flowchart

graph TD
    A["Full Scan reads the one row of treasury_position"] --> B{"Previous Full Scan<br/>measurement exists?"}
    B -->|No| C["Record the value and pass"]
    B -->|Yes| D{"Change between<br/>-500,000 and +500,000?"}
    D -->|Yes| E["Check passes"]
    D -->|No| F["Report a Record Anomaly"]