Skip to content
Rime Documentation

Pipeline Scheduling

Pipelines can run on a schedule, on demand, or both. Scheduling uses cron expressions with full timezone support, including correct handling of daylight saving time transitions.

Setting a schedule

To schedule a pipeline:

  1. Open the pipeline in the DAG builder
  2. Click Schedule in the toolbar
  3. Enter a cron expression or use the visual schedule builder
  4. Select a timezone
  5. Configure the concurrent execution policy
  6. Optionally set a schedule window
  7. Click Save

A pipeline can have one schedule. To run the same pipeline on multiple schedules, create separate pipelines that reference the same steps, or use multiple cron expressions separated by the pipe character (e.g., 0 6 * * 1-5 | 0 12 * * 0 for weekday mornings and Sunday noon).

Cron expressions

Rime uses standard 5-field cron expressions:

minute  hour  day-of-month  month  day-of-week
FieldValuesSpecial characters
Minute0-59* , - /
Hour0-23* , - /
Day of month1-31* , - /
Month1-12* , - /
Day of week0-6 (Sunday = 0)* , - /

Common patterns

ScheduleCron expression
Every hour0 * * * *
Every 6 hours0 */6 * * *
Daily at 2:00 AM0 2 * * *
Weekdays at 6:00 AM0 6 * * 1-5
Every Monday at midnight0 0 * * 1
First of every month at 3:00 AM0 3 1 * *
Every 15 minutes during business hours*/15 9-17 * * 1-5

Visual schedule builder

If you prefer not to write cron expressions, the visual builder lets you select:

  • Frequency — every N minutes, hourly, daily, weekly, or monthly
  • Time — specific hour and minute for daily/weekly/monthly schedules
  • Days — specific days of the week or month

The builder generates the cron expression for you. You can switch between the builder and the raw expression at any time.

Timezone support

Every schedule runs in a specific timezone. Rime uses IANA timezone identifiers (e.g., Pacific/Auckland, Australia/Sydney, America/New_York). The default is Pacific/Auckland.

The timezone determines when the cron expression fires. A schedule of 0 6 * * * in Pacific/Auckland fires at 6:00 AM New Zealand time, regardless of what time that is in UTC.

Daylight saving time

Rime handles DST transitions correctly:

Spring forward (clocks advance). If your schedule is set for a time that does not exist during the transition (e.g., 2:30 AM when clocks skip from 2:00 to 3:00), the pipeline runs at the next valid time after the transition (3:00 AM in this case).

Fall back (clocks retreat). If your schedule is set for a time that occurs twice during the transition (e.g., 2:30 AM when clocks go back from 3:00 to 2:00), the pipeline runs once, during the first occurrence.

In New Zealand, DST transitions happen on the last Sunday of September (spring forward) and the first Sunday of April (fall back). If your pipeline is sensitive to exact timing around these dates, consider using UTC as your timezone.

Manual triggering

You can always trigger a pipeline manually, regardless of whether it has a schedule:

  1. Open the pipeline page
  2. Click Run Now
  3. The pipeline starts immediately

Manual runs are tracked in the same execution history as scheduled runs. The trigger type (manual or scheduled) is recorded in the run metadata.

Concurrent execution policy

When a scheduled run is due but a previous run is still executing, Rime follows the concurrent execution policy you configured:

PolicyBehaviour
Skip (default)The new run is skipped entirely. The next scheduled run proceeds as normal.
QueueThe new run is queued and starts as soon as the current run finishes. At most one run is queued at a time; additional triggers while a run is queued are skipped.
Allow parallelThe new run starts immediately alongside the existing run. Use this only when the pipeline’s steps are safe to run concurrently (e.g., read-only queries).

Choose Skip for most pipelines. Long-running transformations should not stack up. Choose Queue when you need to ensure every scheduled run executes but not concurrently. Avoid Allow parallel unless you are confident there are no write conflicts.

Schedule windows

A schedule window restricts pipeline execution to specific hours. If a cron trigger fires outside the window, the run is skipped.

To set a schedule window:

  1. In the schedule configuration, enable Restrict to window
  2. Set the start time and end time (in the pipeline’s configured timezone)
  3. Optionally restrict to specific days of the week

Example: a pipeline with a cron expression of */30 * * * * (every 30 minutes) and a window of 06:00-22:00 on weekdays will run every 30 minutes between 6 AM and 10 PM, Monday through Friday. Weekend and night-time triggers are skipped.

Schedule windows are useful when:

  • Snowflake warehouse costs need to be contained to business hours
  • Downstream consumers only need data refreshed during specific periods
  • Source systems have maintenance windows where extraction would fail

Retry policies

When a pipeline step fails, the retry policy determines whether it is retried automatically before the step is marked as failed.

Configure retry policies at the pipeline level (applies to all steps) or override per step:

SettingDescriptionDefault
Max retriesNumber of times to retry a failed step before marking it as permanently failed0 (no retries)
Backoff intervalTime to wait before the first retry60 seconds
Backoff multiplierEach subsequent retry waits this many times longer than the previous (exponential backoff)2
Max backoffUpper limit on wait time between retries30 minutes

Example: with max retries = 3, backoff interval = 60s, and multiplier = 2, the retry schedule is:

  1. First retry after 60 seconds
  2. Second retry after 120 seconds
  3. Third retry after 240 seconds

If the step succeeds on any retry, execution continues normally. If all retries are exhausted, the step fails and the pipeline’s failure policy takes effect (see Building Pipelines).

When to use retries

Retries are useful for transient failures:

  • Network timeouts connecting to source systems
  • Snowflake warehouse auto-resume delays
  • External webhook endpoints that are temporarily unavailable

Retries are not useful for deterministic failures:

  • Invalid SQL syntax
  • Missing table references
  • Authentication failures

A step that fails with the same error on every attempt wastes time retrying. If you see the same error across all retry attempts, the issue needs manual investigation.

Next steps