Process millions of records without touching your live store.

Bulk workloads run off your live service entirely

Mark a job as a batch job, and it stops running anywhere near your live storefront traffic. It runs on its own dedicated infrastructure instead, so a 200,000-row import never slows down a single customer.

This isn't a priority setting on shared infrastructure — it's a genuinely separate system. A batch job simply cannot touch what's serving your live traffic.

isolatedcompute — never shares resources with live traffic

Failed records get retried; permanently broken ones get isolated, not lost

Every record gets up to three attempts automatically. If 40,000 records succeed and 12 fail, only those 12 get retried, not the other 39,988.

After three failed attempts, a record is set aside for a week where you can inspect it — never silently dropped.

3 attemptsbefore a record is set aside for review

Limits that stop one job from swamping everything else

Start the same job twice, and the second run waits its turn instead of racing the first — automatically. Need them to run side by side instead? That can be turned on per workflow.

On top of that, your plan sets a cap — one job per store, three per organisation, by default. Hit the limit, and you get a clear message, not a job stuck waiting forever.

1 per store · 3 per orgdefault limits, checked before a job starts

See exactly how far a run has gotten, down to the record

Every run shows you processed, failed, and total counts live — even across nested loops — updated at least every two seconds, even on runs processing millions of records.

A run that finishes with a handful of failures is clearly marked as different from one that fails outright — "40,000 succeeded, 12 didn't" never gets confused with "the whole thing failed."

≤2sprogress updates, even on runs with millions of records

No need to reprocess an entire batch to fix a handful of bad records

Failed records can be rerun on their own — individually or in bulk — without touching what already succeeded. 40,000 successful writes and 80 that hit a timeout? Rerun just those 80.

This matters most on your biggest imports — the bigger the batch, the more time (and duplicate work) you save by fixing only what broke.

rerun-failedreprocess only the records that didn't succeed