Before you start
Use a saved batch workload with a cron or interval schedule and no incremental cursor. For window-filtered SQL, enable data windows and bind their start and end explicitly. Start with the inline workload in Data windows. Save a daily midnight UTC cron schedule, then pause the workload while preparing the historical range. Resume it before creating the backfill. Saving or resuming a live schedule can also create normal scheduled work. Backfills use the normal run execution path. They keep their own window list and do not move the live schedule cursor through the historical range.1. Preview two complete days
Open the workload’s Backfills tab and select Create backfill. Set the start and end to the local equivalents of January 1 and January 3, 2026, at 00:00 UTC. The fields show your browser’s time zone. In Asia/Kolkata, enter 05:30 on both dates. Choose Missing only, one concurrent run, and leave Newest windows first off. Select Preview windows to inspect the included and excluded counts. The HTTP preview below exposes the complete window list and exclusion reasons. Use it when you need to inspect each decision before creation. Use a fresh submission ID and the current saved workload revision:2. Choose reprocessing behavior
Active or uncertain runs are excluded. Unavailable history is not evidence that replay is safe. Inspect preview reasons before changing the policy.
max_active_runs is 1–64, with a default of 1. It is an upper bound for this backfill; overlap rules and available capacity can reduce actual concurrency. run_backwards reverses submission order, but overlapping execution can still finish in another order.
3. Create and inspect
Select Start backfill after reviewing the range and policy. Through HTTP, POST the reviewed request to/api/v1/workloads/{workload_id}/backfills. Creation records the definition, revision, schedule, effective options, parameters, and planned windows for this backfill.
Use the same submission ID and identical request to recover a lost create response. A genuinely new backfill needs a new submission ID. Preview again if the workload changes before acceptance.
For the inline example, January 1 should produce two orders and sales of 50; January 2 should produce two orders and sales of 55. Follow the created run IDs, recorded windows, task states, and any destination commits.
4. Pause, resume, or cancel
In the Backfills tab, open a record to inspect its windows and follow View run links. Use Pause, Resume, or Cancel on an active backfill. Read progress with GET/api/v1/workloads/{workload_id}/backfills/{backfill_id}. Change the backfill with POST to the same route:
pause, resume, and cancel. The retry_notifications action retries exhausted backfill event deliveries with their original event IDs. It does not rerun windows or change a terminal backfill outcome. Pausing holds future submissions. Cancelling stops further planned submissions and requests cancellation of submitted runs. Follow those runs until their final state is confirmed. Neither action rolls back committed writes.
Pausing a backfill is separate from pausing the workload’s live schedule. Check both when stopping all future work.