@kapa.ai We're setting up elementary volume anomalies test a dbt model and the test runs inside an hourly-scheduled Airflow DAG, but each DAG run takes ~2 hours, so effectively we run the test ~12 times per day. We are not setting timestamp column, this is an incremental model . I'd liek to know

It looks like your question got cut off! It seems like you were about to ask something specific about your setup. Could you please complete your question? That said, based on what you've shared so far, here's some relevant context about your setup that may help frame the answer once you complete your query: Your setup summary: •

elementary.volume_anomalies

with no

timestamp_column

• Incremental model • ~12 test runs per day (hourly DAG, ~2 hour duration) Key things to know about this configuration: 1. Snapshot-per-run mode: Without a

timestamp_column

, Elementary records the total row count of the table at each test run and compares those snapshots statistically. [timestamp_column docs] 2. Training period is based on runs, not days: The default training period requires 14 runs (not 14 calendar days) to build a baseline before anomaly detection kicks in. Since you run ~12 times per day, you'll reach the 14-run threshold in about a day. [truncate-and-load discussion] 3. Detection scoping limitation: With no

timestamp_column

, there's no supported way to scope detection to strictly the most recent run. The

backfill_days

parameter controls how many recent runs are checked, but its minimum is 1 day. [detection period limitation] Please go ahead and complete your question — happy to help! 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai How will it work until the baseline is set up with enough data? What is the expected behaviour?

Based on the knowledge sources, here is the expected behavior before the baseline is established: Before Enough Training Data Is Collected The test will pass with a "Not enough data" message. Until Elementary has accumulated enough data points in the

data_monitoring_metrics

table, it will not calculate an anomaly score and will simply pass the test silently. As documented: > "Not enough data to calculate anomaly score" This occurs when there are fewer than 7 training data points (the hardcoded minimum). [Anomaly troubleshooting] Important Caveat for Your Setup Since you run ~12 times per day with no

timestamp_column

, each run adds one data point. This means: • After ~1 day (~12 runs): You'll exceed the 7-point minimum and Elementary will start computing z-scores. • After ~1–2 days (~14 runs): The default training set size is reached. However, with only a small number of data points, the statistical baseline (mean + standard deviation) will be very unstable, meaning false positives are highly likely in the early runs after the minimum threshold is crossed. [baseline stabilization] Recommended Mitigation To prevent false positives from failing your Airflow DAGs during this early period, it is recommended to set

severity: warn

temporarily:

- elementary.volume_anomalies:
    config:
      severity: warn

Once the baseline stabilizes (after a few weeks of runs), you can switch back to

severity: error

. [severity warn] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai If something goes wrong with the masterfeed and the count is very low, the Elementary is likely to stop it in the first few runs until the baseline shifts with the recent data, at what point could that start happening? Is it a couple of hours or a couple of days?

This is an important practical question. Based on the knowledge sources, here is what can be confirmed and where there is uncertainty: When Could Elementary Start Catching a Real Drop? The Hard Minimum: 7 Data Points Elementary will not compute any anomaly score until it has at least 7 training data points in

data_monitoring_metrics

. [Anomaly troubleshooting] At ~12 runs/day, that's roughly ~30–40 minutes before the first anomaly calculation can even happen. The Practical Reality: Baseline Instability However, the knowledge sources are clear that even after crossing the 7-point minimum, the baseline is very noisy and unstable with few data points: > "Day 1–3: Z-scores are wildly unstable, almost everything triggers false positives" > "Day 7–10: Baselines start to stabilize, most false positives disappear" > "Day 14+: Solid baseline" [baseline stabilization] This timeline is described in the context of daily runs. With ~12 runs/day, those "days" compress significantly in terms of data points — but the calendar time for the statistical distribution to stabilize is less clear from the knowledge sources. The Honest Answer The knowledge sources do not explicitly address how quickly the baseline stabilizes when running tests many times per day (vs. once daily). So I cannot give you a precise "it will reliably catch a drop after X hours" answer. What can be said with confidence: • First ~30–40 minutes: No detection at all (fewer than 7 points) • After ~1 day (~12+ runs): Detection starts, but the baseline is likely still noisy and a very large drop would be needed to reliably trigger a failure • After several days of runs: The baseline becomes more stable and moderate drops become detectable If reliable, fast detection of a bad masterfeed load is critical, the knowledge sources suggest complementing

volume_anomalies

with a freshness or recency test, which can alert immediately without needing a baseline: [automated volume] > "For immediate detection of missing data, consider adding a dbt freshness or recency test... These tests are designed to alert you when no new data has arrived within an expected timeframe, regardless of the total row count." 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.