< kapa ai> See below for the current setup Unexpected output Elementary Community #ask-elementary-ai

<@U088WCP3B4P> See below for the current setup. Un...

James Moncreiff

03/31/2026, 2:39 PM

@kapa.ai See below for the current setup. Unexpected output on the browser view, e..g, "Not enough data to calculate anomaly score"

Copy code

models:
  - name: contact_model
    config:
      tags:
        - daily_2am

    # Model-level tests for volume and freshness
    data_tests:
      - elementary.dimension_anomalies:
          arguments:
            timestamp_column: contact_date
            where_expression: "updated_date >= date_sub(current_date, interval 210 day) and contact_date < current_date"
            seasonality: day_of_week
            dimensions:
              - contact_type
            time_bucket:
              period: day
              count: 1
            training_period:
              period: day
              count: 28
            detection_period:
              period: day
              count: 2
            sensitivity: 3
          config:
            tags: ['elementary', 'managing']
            severity: warn

Was working with claude: ⏺️ Problem: dimension_anomalies shows "Not enough data to calculate anomaly score" Despite being live for months, the three dimension_anomalies tests never produce anomaly scores. ⏺️ Observations from data_monitoring_metrics and metrics_anomaly_score: 1. data_monitoring_metrics contains rows for the dimension tests going back to Sept 2025 — there is historical data accumulated 2. For contact_type: 3 distinct dimension values each 3. metrics_anomaly_score has zero rows for the dimension tests — Elementary is not producing anomaly scores at all 5. For volume_anomalies (row_count), metrics_anomaly_score does have rows, with training_start = 2024-03-27 (~2 years back) despite training_period: count: 6 (this is due to the where filter using updated rather than created, but I would have expected training_range to overrule this)

kapa.ai

03/31/2026, 2:39 PM

Looking at your configuration and observations, there are a few likely causes for why

metrics_anomaly_score

has zero rows for your

dimension_anomalies

tests despite

data_monitoring_metrics

having historical data. Key Issues to Investigate 1. arguments: Nesting May Be the Problem Your YAML uses an

arguments:

key to nest the test parameters:

Copy code

- elementary.dimension_anomalies:
    arguments:
      timestamp_column: contact_date
      ...

Based on the configurations shown in community threads and documentation, Elementary anomaly test parameters should be placed directly under the test name, not nested under

arguments:

. For example:

Copy code

- elementary.dimension_anomalies:
    timestamp_column: contact_date
    dimensions:
      - contact_type
    time_bucket:
      period: day
      count: 1
    training_period:
      period: day
      count: 28
    detection_period:
      period: day
      count: 2
    sensitivity: 3

This kind of YAML structure issue can cause the test to compile but not actually collect metrics correctly — or collect metrics without producing anomaly scores. [column_anomalies must be list] 2. Not Enough Training Data Points (< 7) Even if

data_monitoring_metrics

has rows, the

metrics_anomaly_score

table requires at least 7 training data points to calculate an anomaly score. If the metrics are being stored but the time buckets are fragmented or sparse, the threshold may not be met. [Anomaly troubleshooting guide] You can verify this by running:

Copy code

SELECT
    metric_name,
    latest_metric_value,
    training_avg,
    training_stddev,
    anomaly_score,
    is_anomaly
FROM your_schema.metrics_anomaly_score
WHERE full_table_name = 'your_table'
ORDER BY bucket_end DESC;

3. days_back vs training_period Conflict The

where_expression

you have filters data to the last 210 days, but your

training_period

is 28 days. As noted in community discussions, the

where_expression

can interfere with how Elementary determines the training range — which aligns with your observation that

volume_anomalies

shows a

training_start

far outside the expected range. [Anomaly troubleshooting guide] Recommended Next Steps 1. Fix the YAML structure — remove the

arguments:

nesting and place parameters directly under

elementary.dimension_anomalies:

. 2. Force a backfill after fixing the config:dbt test --vars '{"force_metrics_backfill": true}' --select tag:elementary 3. Check
data_monitoring_metrics
to confirm time buckets are being created correctly per dimension value after the config fix. The

arguments:

nesting is the most likely root cause, as similar YAML misconfigurations have been documented as causing metrics to be collected without producing anomaly scores. [column_anomalies must be list] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

James Moncreiff

03/31/2026, 2:55 PM

@kapa.ai https://docs.elementary-data.com/data-tests/anomaly-detection-tests/dimension-anomalies When i check this resource and our own internal documentation it suggests arguments is required We are using 1.10

kapa.ai

03/31/2026, 2:56 PM

You're correct, and I apologize for the confusion in my previous answer. Looking at the official Elementary documentation for

dimension_anomalies

, the

arguments:

nesting is the correct syntax: [dimension_anomalies config]

Copy code

data_tests:
  - elementary.dimension_anomalies:
      arguments:
        dimensions: < columns or sql expressions >
        timestamp_column: < column name >
        where_expression: < sql expression >
        time_bucket:
          period: < time period >
          count: < number of periods >

So your YAML structure with

arguments:

is correct for your dbt version. Given that, the most likely remaining causes for

metrics_anomaly_score

having zero rows are: 1. Known bug with
dimension_anomalies
not picking up configurations correctly — there is a documented open bug where

dimension_anomalies

tests don't properly save configurations. [dimension_anomalies bug] 2. Fewer than 7 training data points in the scoring window — even if

data_monitoring_metrics

has rows,

metrics_anomaly_score

requires at least 7 valid training data points to produce scores. Gaps or sparsity in the bucketed data can prevent this. [Anomaly troubleshooting guide] 3. The
where_expression
interfering with training range — as you observed with

volume_anomalies

, the

where_expression

can affect how Elementary determines the training window, potentially causing unexpected behavior. I'd recommend checking the GitHub issue linked in the community (#1170) to see if there's a known fix or workaround for your version, and verifying your

data_monitoring_metrics

buckets are contiguous and sufficient for the scoring calculation. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

James Moncreiff

04/01/2026, 1:45 PM

@kapa.ai if i remove the where filter, would that consider todays data by default?

kapa.ai

04/01/2026, 1:45 PM

Based on the knowledge sources, when you use a

timestamp_column

, Elementary splits data into time buckets and intentionally excludes the current (incomplete) bucket to avoid comparing incomplete data against completed historical buckets. Specifically, the knowledge sources note: > "the last bucket (today) is intentionally excluded to avoid this exact issue" [volume anomalies config] So if you remove the

where_expression

, Elementary will: • Use your

timestamp_column

(

contact_date

) to bucket data daily • Look back according to your

training_period

(28 days) from the current run time • Exclude today's incomplete bucket by default, comparing the most recent completed day(s) against the training history This means removing the filter should not cause today's partial data to skew your anomaly detection — Elementary handles that automatically when a

timestamp_column

is configured. However, the knowledge sources do not explicitly confirm whether removing the

where_expression

alone will resolve the

metrics_anomaly_score

having zero rows for your

dimension_anomalies

tests. The training window behavior difference you observed (volume_anomalies showing

training_start

going back ~2 years) does suggest the

where_expression

updated_date

was interfering with how Elementary determined the training range, so removing it may help normalize that behavior. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

25 Views

Open in Slack

Previous Next