Scheduling with the Built-in Scheduler

DataRecs has its own built-in scheduler — a cron-based trigger attached directly to a job. For teams that already orchestrate from Apache Airflow, see Scheduling with Airflow instead; the two are independent, and a job can be triggered by either (or both).

Create a schedule

A schedule needs the job it applies to, a 5-field cron expression, and optionally a timezone (defaults to UTC) and runtime parameters forwarded to each triggered run.

CLI

datarecs jobs schedules create \
  --job-id <job-id> \
  --workspace-id <workspace-id> \
  --cron "0 2 * * *" \
  --timezone Europe/London

Terraform

resource "datarecs_job_schedule" "nightly" {
  job_id          = datarecs_job.daily_check.id
  workspace_id    = datarecs_workspace.production.id
  cron_expression = "0 2 * * *"
  timezone        = "Europe/London"
}

REST API

curl -X POST https://api.datarecs.io/jobs/<job-id>/schedules?workspaceId=<workspace-id> \
  -H "Authorization: Bearer $DATARECS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "job_id": "<job-id>",
    "cron_expression": "0 2 * * *",
    "timezone": "Europe/London"
  }'

cron_expression is a standard 5-field expression (minute hour day-of-month month day-of-week). timezone is an IANA name (Europe/London, America/New_York, …) used to interpret the cron fields — see Temporal Handling for how DataRecs resolves timezones elsewhere in a job. enabled defaults to true; params are runtime parameters forwarded to every triggered run, the same as a manual jobs runs trigger --param.

List, update, and delete schedules

CLI

datarecs jobs schedules list --job-id <job-id> --workspace-id <workspace-id>

datarecs jobs schedules update \
  --job-id <job-id> --schedule-id <schedule-id> --workspace-id <workspace-id> \
  --cron "0 3 * * *" --no-enabled

datarecs jobs schedules delete \
  --job-id <job-id> --schedule-id <schedule-id> --workspace-id <workspace-id>

--no-enabled disables a schedule without deleting it — useful for pausing a job’s automatic runs temporarily.

REST API

curl "https://api.datarecs.io/jobs/<job-id>/schedules?workspaceId=<workspace-id>" \
  -H "Authorization: Bearer $DATARECS_API_KEY"

curl -X PATCH "https://api.datarecs.io/jobs/<job-id>/schedules/<schedule-id>?workspaceId=<workspace-id>" \
  -H "Authorization: Bearer $DATARECS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}'

curl -X DELETE "https://api.datarecs.io/jobs/<job-id>/schedules/<schedule-id>?workspaceId=<workspace-id>" \
  -H "Authorization: Bearer $DATARECS_API_KEY"

What happens when a schedule fires

A scheduled run is triggered the same way a manual jobs runs trigger is — it goes through the same run lifecycle, the same limits (a scheduled trigger while you’re at your concurrent-run limit is rejected the same as a manual one), and the same webhook/email notifications. There’s nothing schedule-specific to subscribe to — subscribe to the run lifecycle events as usual.

Next steps

• Configuring a Reconciliation Job
• Scheduling with Airflow — the alternative for teams already orchestrating externally.
• Reconciliation Run Lifecycle