Process bulk workloads without touching your live service. Isolated compute. Automatic retries. Real concurrency limits.

Bulk workloads run off your live service entirely

Mark a trigger as a batch job and it stops running on the same service that handles your live storefront traffic. It's queued and picked up by dedicated, AWS-managed compute instead — so a 200,000-row import can't add latency, memory pressure, or contention to a single concurrent live request.

This isn't a priority flag on shared infrastructure — it's a genuinely separate execution path, with its own isolated IAM role. A batch job literally cannot touch the resources serving your API.

isolatedcompute — batch jobs never share resources with live traffic

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

Each queued unit of work gets up to three delivery attempts automatically. Failures are reported at the record level, not the batch level — so if 40,000 records in a run succeed and 12 fail on the first pass, only those 12 are retried, not the other 39,988.

After three failed attempts, a record moves to a dedicated dead-letter queue with a seven-day retention window instead of disappearing. Nothing is silently dropped — it's isolated somewhere you can go inspect it.

3 attemptsbefore a record moves to an inspectable dead-letter queue

Two independent limits keep batch jobs from overwhelming your data or your plan

A second trigger for the same workflow, route, and environment queues behind the first by default rather than racing it — and drains automatically once the in-flight run finishes. That default can be relaxed per route if a workflow is genuinely safe to run concurrently against itself.

On top of that, plan-level caps apply before a run is even accepted: one concurrent job per store, three per organisation by default, rejected with a clear error rather than silently queued forever if you're already at the limit.

1 per store · 3 per orgdefault concurrent-run caps, enforced before a job is accepted

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

Every run tracks processed, failed, and total counts — including progress through nested loops — and reports it live rather than only at completion. Progress is flushed at most every two seconds even on runs processing millions of records, so you get real visibility without the tracking itself becoming a bottleneck.

A run that finishes with a handful of failures is marked distinctly from one that fails outright, so "40,000 succeeded, 12 didn't" never gets conflated with "the whole thing failed."

≤2sprogress flush interval, even on runs processing millions of records

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

Failed records can be rerun individually or in bulk, up to a configurable maximum number of attempts, without touching the records that already succeeded. A run with 40,000 successful writes and 80 that hit a transient downstream timeout gets fixed by rerunning those 80 — not by re-triggering the whole import from scratch.

That matters most on the imports too large to comfortably rerun in full: the bigger the batch, the more a "just fix what broke" workflow saves in both time and duplicate side effects.

rerun-failedreprocess only the records that didn't succeed