;
};
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 [Partition Timeline Tool](https://app.synq.io/partition-timeline-test).
## Understanding time partitioning
Every monitor requires 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 frequently to measure the data — daily, hourly, or down to minutes — and optionally define a delay to account for late-arriving data.
## 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.
By default, all monitors execute internally in **UTC** for consistency and easier debugging. You can still define schedules in your local time zone — the platform automatically converts this to the correct UTC schedule under the hood.
### 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.
export const InteractiveTimeline = () => {
const [granularity, setGranularity] = React.useState("hourly");
const [ignoreLastPartition, setIgnoreLastPartition] = React.useState(0);
const [delayMinutes, setDelayMinutes] = React.useState(0);
const [timezone, setTimezone] = React.useState("UTC");
const [partitionsToShow, setPartitionsToShow] = React.useState(4);
return