Observability Examples

Catching an ETL that stopped loading

Context. A retail analytics pipeline is expected to append 30,000 to 60,000 rows a day to orders_daily. Volume Tracking has been on for two months, and Qualytics AI-authored a 1 Day Volumetric check with Absolute Value comparison, Min = 25,000, Max = 70,000.

What happens. Overnight, the ETL job fails silently. The next day, the sweep records 0 rows for the day. The measurement falls below the Min threshold, an anomaly is raised, and the container's heatmap turns orange for that day.

Why it works. Absolute Value on a stable range fires immediately when the count drops out of the expected band. The 1 Day window catches the outage on the very next measurement instead of averaging it away.

Detecting stale data from a lagging source

Context. A CRM extract lands in customers_snapshot every four hours. The team enables Freshness Tracking and AI-authors a check with Maximum Age = 6 Hours to allow for some slack on late arrivals.

What happens. A permissions issue on the source causes the extract to stop running for a day. The freshness sweep continues to record last_modification_time from the last successful load. Once the age of the most recent modification passes 6 hours, an anomaly is raised. The freshness chart shows a bar exceeding the Maximum Age threshold line.

Why it works. Freshness surfaces silent failures that Volumetric would miss (no rows were removed; nothing new is being added). The 6-hour Maximum Age is generous enough to avoid false positives from timing jitter but tight enough to catch a day-long outage.

Guarding a computed metric with a fixed range

Context. A payments table has a refund_ratio field that should always be between 0 and 0.15. A Metric check is authored on the field with Absolute Value, Min = 0, Max = 0.15.

What happens. A pricing bug causes a batch of orders to be flagged as fully refunded. The next scan produces a refund_ratio of 0.32. The Metric chart records the measurement outside the range and raises an anomaly.

Why it works. Absolute Value on a hard business bound catches the value as soon as it crosses the ceiling, even if the ratio drifted slowly across previous scans (nothing before the incident had crossed the boundary).

Catching a percentage swing on a moving baseline

Context. A subscription business tracks active_users on a metric check. The baseline grows week over week, so Absolute Value would need constant retuning. The team picks Percentage Change with Min = -0.05, Max = 0.10 (allow up to 10% growth and 5% loss between scans).

What happens. A misconfigured feature flag disables sign-ups for one region. The next scan records a 12% drop in active_users. The Percentage Change measurement breaks the -5% floor. An anomaly is raised even though the absolute value is still within the historical band.

Why it works. Percentage Change grades measurements against the previous value, so the threshold scales with the baseline. A 12% drop is meaningful regardless of whether the baseline is 10,000 or 10,000,000.

Combining Measures and Metrics for full coverage

Context. A team is onboarding a new critical table fact_transactions. They want to catch three failure modes: rows stop arriving, data stops updating, and the average value drifts.

What happens.

• Volumetric check on 1 Day window (Percentage Change, Min = -0.20, Max = 0.30, so alerts fire outside a -20% to +30% band): catches unexpected daily drops or spikes.
• Freshness check with Maximum Age = 4 Hours: catches load lag.
• Metric check on avg_amount (Absolute Value, Min = 15, Max = 250): catches upstream calculation drift.

Together, the three checks cover volume, timing, and content. A regression in any one dimension raises an anomaly that appears on the same datastore's Anomalies view.

Why it works. The three checks address orthogonal failure modes, so they do not overlap. Each is cheap: Volumetric and Freshness update automatically from the sweep, and the Metric check runs opportunistically whenever a scan touches the field.