Skip to main content

Generate your anomaly test with Elementary AI

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

​
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

​
Comparison with other freshness tests

​
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