> ## Documentation Index > Fetch the complete documentation index at: https://docs.elementary-data.com/llms.txt > Use this file to discover all available pages before exploring further. # data_freshness_sla > [card] [Generate your anomaly test with Elementary AI](https://elementary-data.com/community) > > Let our Slack chatbot create the anomaly test you need. `elementary.data_freshness_sla` Verifies that data in a model was updated before a specified SLA deadline time. This test checks the maximum timestamp value of a specified column in your data to determine whether the data was actually refreshed before your deadline. Unlike `freshness_anomalies` (which uses z-score based anomaly detection as a dbt test, or ML-based detection in Elementary Cloud), this test validates against a fixed, explicit SLA time, making it ideal when you have a concrete contractual or operational deadline. Unlike `execution_sla` (which only checks if the dbt model *ran* on time), `data_freshness_sla` checks whether the actual *data* is fresh. A pipeline can run successfully but still serve stale data if, for example, an upstream source didn't update. This test catches that. ### Use Case "Was the data in my model updated before 7 AM Pacific today?" ### Test Logic 1. If today is not a scheduled check day → **PASS** (skip) 2. Query the model for the maximum value of `timestamp_column` 3. If the max timestamp is from today → **PASS** (data is fresh) 4. If the SLA deadline hasn't passed yet → **PASS** (still time) 5. If the max timestamp is from a previous day → **FAIL** (DATA\_STALE) 6. If no data exists in the table → **FAIL** (NO\_DATA) ### Test configuration *Required configuration: `timestamp_column`, `sla_time`, `timezone`* 
  `data_tests:
    -- elementary.data_freshness_sla:
      arguments:
        timestamp_column: column name # Required - timestamp column to check for freshness
        sla_time: string # Required - e.g., "07:00", "7am", "2:30pm", "14:30"
        timezone: string # Required - IANA timezone name, e.g., "America/Los_Angeles"
        day_of_week: string | array # Optional - Day(s) to check: "Monday" or ["Monday", "Wednesday"]
        day_of_month: int | array # Optional - Day(s) of month to check: 1 or [1, 15]
        where_expression: sql expression # Optional - filter the data before checking`
```yml Models theme={null} models: - name: < model name > data_tests: - elementary.data_freshness_sla: arguments: timestamp_column: < column name > # Required sla_time: < deadline time > # Required - e.g., "07:00", "7am", "2:30pm" timezone: < IANA timezone > # Required - e.g., "America/Los_Angeles" day_of_week: < day or array > # Optional day_of_month: < day or array > # Optional where_expression: < sql expression > # Optional ``` ```yml Daily check theme={null} models: - name: daily_revenue data_tests: - elementary.data_freshness_sla: arguments: timestamp_column: updated_at sla_time: "07:00" timezone: "America/Los_Angeles" config: tags: ["elementary"] severity: error ``` ```yml With filter expression theme={null} models: - name: daily_events data_tests: - elementary.data_freshness_sla: arguments: timestamp_column: event_timestamp sla_time: "6am" timezone: "Europe/Amsterdam" where_expression: "event_type = 'completed'" config: tags: ["elementary"] ``` ```yml Weekly - only Mondays theme={null} models: - name: weekly_report_data data_tests: - elementary.data_freshness_sla: arguments: timestamp_column: report_date sla_time: "09:00" timezone: "Asia/Tokyo" day_of_week: ["Monday"] config: tags: ["elementary"] ``` ### Features * **Data-level freshness**: Checks actual data timestamps, not just pipeline execution time * **Flexible time formats**: Supports `"07:00"`, `"7am"`, `"2:30pm"`, `"14:30"`, and other common formats * **IANA timezone support**: Uses standard timezone names like `"America/Los_Angeles"`, `"Europe/Amsterdam"`, etc. * **Automatic DST handling**: Uses `pytz` for timezone conversions with automatic daylight saving time handling * **Database-agnostic**: All timezone logic happens at compile time * **Schedule filters**: Optional `day_of_week` and `day_of_month` parameters to check only specific days * **Filter support**: Use `where_expression` to check freshness of a specific subset of data ### Parameters | Parameter | Required | Description | | - | - | - | | `timestamp_column` | Yes | Column name containing timestamps to check for freshness | | `sla_time` | Yes | Deadline time (e.g., `"07:00"`, `"7am"`, `"2:30pm"`) | | `timezone` | Yes | IANA timezone name (e.g., `"America/Los_Angeles"`) | | `day_of_week` | No | Day(s) to check: `"Monday"` or `["Monday", "Wednesday"]` | | `day_of_month` | No | Day(s) of month to check: `1` or `[1, 15]` | | `where_expression` | No | SQL expression to filter the data before checking | ### Comparison with other freshness tests | Feature | `data_freshness_sla` | `freshness_anomalies` | `execution_sla` | | - | - | - | - | | What it checks | Actual data freshness (timestamps in the data) | Actual data freshness (timestamps in the data) | Pipeline execution (did the model run?) | | Detection method | Fixed SLA deadline | Z-score (dbt test) / ML (Cloud) | Fixed SLA deadline | | Best for | Contractual/operational deadlines on data | Detecting unexpected delays in data updates | Ensuring the pipeline itself ran on time | | Works with sources | Yes | Yes | No (models only) | ### Notes * The `timestamp_column` values are assumed to be in **UTC** (or timezone-naive timestamps that represent UTC). If your data stores local timestamps, the comparison may be incorrect. * If both `day_of_week` and `day_of_month` are set, the test uses OR logic (checks if either matches) * The test passes if the SLA deadline hasn't been reached yet, giving your data time to be updated This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.