Short answer: the anomaly test is behaving as designed. Why it’s passing even though your table hasn’t updated since 2024: - Freshness anomaly tests compare recent buckets to historical behavior; they don’t enforce a fixed “must be newer than X” threshold. If your table has been stale for the entire training window, the “normal” learned behavior is also stale, so no anomaly is detected. [[freshness_anomalies](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies); [Slack thread](https://slack.com/archives/C02CTC89LAX/p1684401442974139)] - This is true for both freshness_anomalies and event_freshness_anomalies. Event freshness measures delay between event time and load time (or “now” vs. last event if no update column). If delays are consistently large in both training and detection periods, the test will pass. [[event_freshness_anomalies](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/event-freshness-anomalies)] Common pitfalls relevant to your config: - anomaly_direction: You don’t need to set this; it defaults to spike (delays). Setting it doesn’t change behavior. [[event_freshness config](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/event-freshness-anomalies#test-configuration); [Slack note](https://slack.com/archives/C02CTC89LAX/p1685592068134349)] - If the table has been stale across your entire training_period (30 days) and detection_period (7 days), the model “learns” that staleness is normal, so no anomaly is flagged. [[Slack thread](https://slack.com/archives/C02CTC89LAX/p1684401442974139); [Slack thread](https://slack.com/archives/C02CTC89LAX/p1703157711512959)] What you can do: - If you want a hard freshness threshold (fail when data is older than X), use a threshold-style test (e.g., dbt source freshness for sources, or a generic/3rd‑party recency test) rather than an anomaly test. Elementary’s anomaly tests don’t support a fixed threshold. [[Slack guidance](https://slack.com/archives/C02CTC89LAX/p1683294589948059); [Slack guidance](https://slack.com/archives/C02CTC89LAX/p1682503992494309); [Slack guidance](https://slack.com/archives/C02CTC89LAX/p1684401442974139)] - If you still prefer anomalies, ensure your training_period includes “healthy” periods so the model can learn that being up-to-date is normal; then a continued delay becomes an anomaly. You can also increase sensitivity, but it won’t help if all training data is stale. [[freshness_anomalies](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies); [Slack tip](https://slack.com/archives/C02CTC89LAX/p1703157711512959)] Quick checklist: - Is your event_timestamp_column correct? For event freshness without update_timestamp_column, the metric is “now minus last event time.” [[event_freshness_anomalies](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/event-freshness-anomalies)] - Do you truly have no newer events within both the 30‑day training window and the 7‑day detection window? If yes, the pass is expected. [[Slack thread](https://slack.com/archives/C02CTC89LAX/p1684401442974139)] If you want a code-based threshold test (fail if last event is older than N days), consider replacing this anomaly test with a threshold test (e.g., dbt’s source freshness for sources, or a custom/generic test) as suggested in the threads. [[Slack guidance](https://slack.com/archives/C02CTC89LAX/p1683294589948059); [Slack guidance](https://slack.com/archives/C02CTC89LAX/p1682503992494309)]