What is an Encoding Job?
An Encoding Job is the smallest processing unit in Transloadit, such as one video encode or image resize executed on an encoding machine. Despite the historical name, Robot operations are scheduled as Encoding Jobs, including imports, exports, and metadata extraction, not only codec work.
How Encoding Jobs work
Within a Transloadit Assembly, the workflow graph turns applicable processing operations on assets into schedulable work. Dependency edges hold a downstream task until the outputs it consumes are ready, while unrelated branches can progress independently. The job is therefore an execution and capacity concern, whereas the Assembly is the coordinating workflow visible to an integration and the unit at which replays are requested. Status aggregation maps these granular outcomes back to the larger request.
Key facts
- One Assembly can produce many jobs when Steps fan out across uploaded files or create several derivatives, so the number of API submissions is not a reliable measure of processing demand.
- An Encoding Job error that its Step’s
ignore_errorssetting does not cover ends the whole Assembly and starts a best-effort abort of the remaining jobs, including those in independent branches. Recovery happens at the Assembly level: replaying the Assembly re-runs the workflow as a new Assembly rather than retrying one job. - Job cost and duration vary with input complexity and operation type, not only file size, and a Turbo Mode video encode splits into segment jobs that occupy job slots themselves.
When Encoding Jobs matter
Developers estimate job counts when planning workflow capacity, cost, and concurrency. Recovery happens at the Assembly level: a crashed Assembly can be replayed as a new Assembly, so design workflows with the cost of re-running them in mind rather than assuming an individual failed job can be retried in isolation.