Skip to content

Concepts

Scheduling

Configure replication schedules, maintenance windows, and cron-based job timing in Datamotive.

Product
Datamotive Platform
Version
v1.0
Documentation status
Published
Last updated
Updated
Reading time
1 min read

Scheduling controls when replication cycles run, when maintenance tasks execute, and how Datamotive handles conflicts between overlapping jobs.

Replication interval

The primary schedule for a protection plan is the replication interval, which sets how often an incremental cycle runs. A shorter interval improves RPO at the cost of more frequent API calls and slightly higher CPU usage on the appliance.

IntervalMaximum RPOTypical use case
5 minutes5 minutesTier 1 databases, financial transaction systems
15 minutes15 minutesBusiness-critical applications, ERP systems
30 minutes30 minutesStandard enterprise workloads
1 hour1 hourDevelopment, test, or low-priority systems
4 hours4 hoursArchive workloads or low-churn file servers

Maintenance windows

Maintenance windows restrict when certain job types run. Use them to prevent resource-intensive tasks (initial seeds, consistency checks) from running during peak business hours.

Configure maintenance windows in Settings then Schedules. Each window specifies:

  • Days of the week (for example: Monday through Friday)
  • Start and end time in UTC
  • Job types allowed within the window (initial seed, consistency check, or both)

Incremental replication cycles are not affected by maintenance windows: they always run on the configured interval to maintain RPO.

Cron expressions

For consistency checks and maintenance tasks, Datamotive supports standard five-field cron expressions:

minute  hour  day-of-month  month  day-of-week
  0      2        *           *        0        → Every Sunday at 02:00 UTC
  0     22        *           *       1-5       → Monday to Friday at 22:00 UTC

Cron scheduling is available under Plans then Advanced settings then Consistency check schedule.

Job conflict handling

If a scheduled job would start while the previous cycle is still running, the control plane skips the new instance and logs a Skipped: cycle in progress event. The next scheduled instance runs normally. This prevents overlapping cycles from competing for the same snapshot resources.

For one-off manual triggers (for example, Run now in the console), the job is queued and starts immediately after the in-progress cycle completes.

Related docs

Was this page helpful?