Yes, adjusting the

detection_period

is one way to backtest if your Elementary Data alerts work as intended. The

detection_period

defines the timeframe for which data points could be flagged as anomalous. ## How to adjust the detection_period You can configure the

detection_period

in your dbt model tests like this:

yaml models:   - name: your_model_name     tests:       - elementary.volume_anomalies:           detection_period:             period: day  # supported periods: day, week, month             count: 30    # adjust this number based on how far back you want to test

By increasing the

count

value (default is 2 days), you're extending the period during which Elementary will look for anomalies [Anomaly Detection Configuration](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/detection-period). This allows you to "backtest" by including historical anomalies in your detection window. ## Important considerations: 1. Detection vs. Training Period: Be aware that by default, the detection period is included in the training period when calculating averages and standard deviations. Some users have noted this might not be ideal since outliers you want to detect shouldn't be part of your baseline expectations. 2. Materialization impact: The

detection_period

works differently depending on your table materialization: - For regular tables and views: It simply defines the detection period - For incremental models and sources: It defines both the detection period and the period for which metrics will be re-calculated 3. Simulation: For some settings, Elementary offers a simulation feature. You can use the "Simulate Configuration" button to see how changes might impact your results before saving [Monitors Configuration](https://docs.elementary-data.com/features/anomaly-detection/monitors-configuration). If you're specifically testing hourly data, note that there have been some issues with using

hour

as a period in the past, though this may have been addressed in newer versions. I hope this helps with your backtesting! Let me know if you need more specific guidance.

You've identified an important issue with Elementary's anomaly detection - the fact that the detection period is included in the training period calculations by default, which can dilute the sensitivity of anomaly detection. Currently, there's no official parameter to completely separate the detection period from the training period, but there is a workaround using the

anomaly_exclude_metrics

parameter. This allows you to exclude the latest data point (which would be in your detection period) from calculations:

yaml - elementary.volume_anomalies:     anomaly_exclude_metrics: "MAX(bucket_end) OVER (partition by metric_name, full_table_name, column_name, dimension, dimension_value, bucket_seasonality order by bucket_end asc rows between unbounded preceding and unbounded following) = bucket_end"

This expression excludes the latest data point from both the detection and training periods [Exclude detection period from training period?](https://github.com/elementary-data/elementary/issues/1491#issuecomment-2384317102). Several users have reported this issue and there are open GitHub issues tracking it: 1. [Issue #1491](https://github.com/elementary-data/elementary/issues/1491) - Specifically about excluding detection period from training period 2. [Issue #1560](https://github.com/elementary-data/elementary/issues/1560) - Related to how detection period values are included in AVG calculations The Elementary team has acknowledged this behavior was originally intentional but they're open to changing it. They've mentioned they're looking into solutions, but as of now, the workaround above is the best available option. Note that this is a somewhat advanced configuration and might require careful testing to ensure it works as expected in your specific scenario. Let me know if you need any clarification on implementing this workaround!

To backtest your alerts by extending the detection period to 12 months, you need to understand how Elementary Data handles historical data and how to properly view the results. When you change your detection period to 12 months, Elementary will look for anomalies in that timeframe, but there are several factors that affect what you'll actually see in the

metrics_anomaly_score

table: 1. Training Period Requirements: Elementary requires sufficient historical data to detect anomalies. By default, it needs at least 14 days of data with a minimum of 14 rows [Training Period](https://docs.elementary-data.com/guides/how-anomaly-detection-works#training-period). 2. Data Collection Method: How data is collected depends on whether you've configured a timestamp column: - With a timestamp column: Elementary collects metrics by time buckets - Without a timestamp column: Elementary builds up data over multiple test runs [Anomaly Tests Troubleshooting](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/Anomaly-troubleshooting-guide) 3. Metrics Refresh: When changing configuration parameters like detection_period, you need to refresh your metrics:

dbt run --select data_monitoring_metrics --full-refresh

Then run your tests again [Anomaly Troubleshooting Guide](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/Anomaly-troubleshooting-guide). 4. CLI Report Options: To see more historical data in the Elementary UI report, use:

edr report --days-back 365

This shows data for a longer period in the report [Slack forum user question](https://slack.com/archives/C02CTC89LAX/p1701813698582889). If you're still not seeing 12 months of data in

metrics_anomaly_score

, check: - Whether your data source actually has 12 months of historical data - If your timestamp column contains null values or incorrect formats - That you've run the tests enough times to collect sufficient data points You can verify data collection with this query:

sql SELECT     metric_timestamp,     metric_value,     COUNT(*) as metrics_per_bucket FROM your_schema.data_monitoring_metrics WHERE table_name = 'your_table' GROUP BY metric_timestamp, metric_value ORDER BY metric_timestamp DESC;

This will help you understand if metrics are being collected properly across your desired timeframe.

To set up your tests so that they generate a warning (and not a failure/error), you should configure the test's severity to warn. This can be done in your test configuration using the standard dbt config syntax. For example:

yaml tests:   - not_null:       config:         severity: warn

Or for an Elementary anomaly detection test:

yaml - elementary.volume_anomalies:     config:       severity: warn

This approach works for both generic dbt tests and Elementary tests. Setting

severity: warn

ensures that if the test fails, it will be marked as a warning rather than an error, and will not cause your dbt run to exit with a failure code or block downstream models from running. This is especially useful if you want to monitor issues without interrupting your data pipeline [see Slack discussion](https://slack.com/archives/C02CTC89LAX/p1665067912877829), [another example](https://slack.com/archives/C02CTC89LAX/p1709141168413439). You can also set the severity at the project level in your

dbt_project.yml

to apply to all tests, but be aware that this will affect all tests, not just Elementary ones. If you want to apply it only to Elementary tests, you can use:

yaml tests:   elementary:     +severity: warn

However, some users have reported that this project-level config may not always work as expected for all Elementary test types and versions, so specifying it per test is the most reliable method [see Slack discussion](https://slack.com/archives/C02CTC89LAX/p1711559815403719). Let me know if you need an example for a specific test type!

Certainly! Here’s an example of configuring an Elementary anomaly detection test—specifically, a

volume_anomalies

test—so that it issues a warning instead of a failure:

yaml models:   - name: your_model_name     tests:       - elementary.volume_anomalies:           timestamp_column: your_timestamp_column           config:             severity: warn

This configuration ensures that if an anomaly is detected, it will be reported as a warning and will not cause your dbt run to fail or block downstream models. This approach is confirmed in multiple community discussions and is the recommended way to set severity for Elementary tests [Slack forum example](https://slack.com/archives/C02CTC89LAX/p1709141168413439) [Another example](https://slack.com/archives/C02CTC89LAX/p1688028623624369). Let me know if you need an example for a different test type!

To add a tag to your

conversions

YAML configuration, you should add the

tags

key at the appropriate level. According to the knowledge sources, tags for tests can be added directly under the test configuration, and tags for models can be added under the

config

key at the model level. However, be aware that currently, Elementary only displays model-level tags in the UI and alerts, while test-level tags are supported in alerts but not yet in the dashboard UI [Slack forum user question](https://slack.com/archives/C02CTC89LAX/p1693312098704869), [Best-practices: Governance for observability](https://docs.elementary-data.com/best-practices/governance-for-observability). Here’s how you can add a tag to your test:

yaml - name: conversions   config:     elementary:       timestamp_column: visit_date     tags: [marketing]  # Model-level tag   columns:     - name: visit_date       data_type: timestamp      - name: conversion_rate       data_type: double       tests:         - elementary.column_anomalies:             name: conversion_rate             timestamp_column: visit_date             config:               severity: warn             tags: [conversion-metrics]  # Test-level tag             column_anomalies:               - average               - variance               - standard_deviation               - min               - max             meta:               description: "New billing members over total pricing page views"             time_bucket:               period: day               count: 1             anomaly_sensitivity: 3             detection_period:               period: month               count: 12             training_period:               period: week               count: 10             detection_delay:               period: day               count: 1             seasonality: day_of_week

- Use

tags: [your-tag]

under

config

for model-level tags. - Use

tags: [your-tag]

directly under the test for test-level tags. Remember, only model-level tags will currently appear in the Elementary dashboard, but test-level tags will be included in alerts and in the test results table [Slack forum user question](https://slack.com/archives/C02CTC89LAX/p1693312098704869), [Best-practices: Governance for observability](https://docs.elementary-data.com/best-practices/governance-for-observability). If you need the tag to be visible in the dashboard, prefer the model-level tag. If you want to use the tag for alert routing or filtering in alerts, you can use the test-level tag.

Having a model-level config in your YAML file does not inherently "mess up" the file, as long as it is structured correctly according to dbt and Elementary's requirements. Model-level configs (such as

tags

,

elementary

, or other dbt configs) are supported and commonly used. For example:

yaml - name: conversions   config:     elementary:       timestamp_column: visit_date     tags: [marketing]   columns:     ...

This is a valid and supported pattern. However, if the YAML structure is incorrect (for example, incorrect indentation or placing test definitions inside the

config

block), it can cause issues. One common mistake is putting tests inside the

config

block, which will prevent them from running, as noted by a user who resolved their issue by moving the test definition out of the

config

block [Slack forum user question](https://slack.com/archives/C02CTC89LAX/p1730300160839989). So, as long as you follow the correct YAML structure, having a model-level config will not cause problems. If you encounter issues, double-check your indentation and placement of keys.