Skip to main content
When defining scheduled monitors, you can control when and how your data is evaluated through time partitioning and scheduling. These settings determine both the time window a monitor measures (e.g. “yesterday’s data”) and when the measurement occurs (e.g. “4 AM New York time”). This guide explains how scheduling and time partitioning interact, the available configurations, and how to visualize them using the .

​
Understanding time partitioning

Most monitors use a time partition field, such as created_at or date. This field defines how data is grouped over time and is used to determine which records belong to a given measurement window. You can then choose how often to measure the data (daily, hourly, or down to minutes) and optionally define a delay to account for late-arriving data.

​
No time segmentation

If the table has no column that tells when a row arrived, turn on No time segmentation in the monitor form. The monitor then computes the metric over the whole table on each run, on the schedule you choose. It reads the whole table each time, so it can cost more in your warehouse than a monitor with a time partition field. It has no historical backfill: anomaly detection starts to learn from the first run.

​
Scheduling options

Each monitor run is defined by three parameters:
  1. Frequency – how often the monitor runs (e.g. daily, hourly).
  2. Partition time – the timestamp field used to group data.
  3. Time zone and offset – when in the day the monitor executes.
Monitors run in UTC. You can define a schedule in your local time zone, and Coalesce Quality converts it to the matching UTC schedule.

​
Common scheduling examples

  • Daily at midnight UTC Measures data for the previous calendar day.
  • Daily at 2 AM UTC Measures data for the previous calendar day at 2AM (useful for delayed ETL jobs).
  • Daily at midnight New York Runs at 5 AM UTC but measures midnight → midnight in the New York time zone.
These combinations allow teams to align monitoring with pipeline completion times and business-day boundaries.

​
Handling data delays

Many teams have ETL pipelines that complete several hours after midnight. In these cases, you can configure monitors to delay execution (for example, run at 4 AM but still measure the previous day’s partition). This ensures freshness or volume checks evaluate complete data instead of partially loaded partitions.

​
Advanced configurations

The platform supports advanced scheduling behaviors to cover all data-readiness scenarios:
  • Ignore last partition – Skip the most recent day/hour if data isn’t yet ready (useful for delayed ingestion).
These options allow you to model both CRON-style schedules and dynamic, event-driven monitoring.

​
Visualizing your configuration

You can preview how your scheduling and partitioning settings interact using the interactive partition timeline tool below. It helps you confirm exactly what data window each run will measure and when it will execute.