What is a Priority Job Slot?
A Priority Job Slot is one unit of the Live Queue processing capacity included with a Transloadit subscription plan. Every Robot type has a fixed, documented slot cost: a /video/encode job occupies 60 slots, while an /image/resize job occupies 5. A Workspace’s slot allowance applies separately in each region.
How Priority Job Slots work
Priority Job Slots express weighted scheduler capacity rather than a simple count of active jobs. Each job’s cost is a fixed value configured for its Robot type, with only a few Robots varying the cost by their Instructions. A few expensive video jobs can therefore consume more of the allowance than many lightweight image jobs. Exceeding the allowance does not fail work: excess live jobs trickle down into the Backup Queue and are automatically re-enqueued as running jobs complete and free slots. This allowance is separate from the Rate Limiter’s Assembly-creation limits, so a workload can stay under those limits and still queue for slots.
Key facts
- 1Slot costs are published constants per Robot type.
/video/encodecurrently costs 60 slots, the highest entry in the table, while/image/resizecosts 5 and/s3/storecosts 2. These values let you calculate required capacity instead of estimating it. - 2The slot allowance comes from the subscription plan and acts per Workspace and per region: a plan with 500 Priority Job Slots provides 500 in each region Transloadit operates in, not one global pool.
- 3Sending more live jobs than the allowance covers does not reject them; the excess trickles down into the Backup Queue and returns to the Live Queue as soon as completed jobs free up the Workspace’s slots.
When Priority Job Slots matter
Sum the documented slot costs of the Robots your workload runs concurrently to predict when jobs will start queueing, and reserve a higher allowance before a predictable surge. Steps that do not need real-time processing can set "queue": "batch" so their jobs avoid consuming Priority Job Slots.
Common use cases for platform workflows
These examples cover platform workflows broadly, not specifically Priority Job Slots.
- Running repeatable upload, import, processing, AI, storage, and notification pipelines.
- Tracking long-running media work independently from an application request.
- Referencing centrally stored credentials by name instead of sending storage secrets with each request.
Working with platform workflows
This guidance covers platform workflows broadly, not just Priority Job Slots.
A client authenticates and submits files or references together with workflow instructions. The platform validates the request, schedules dependent operations, records state transitions, and exposes results through a response, polling endpoint, or notification.
Platform concepts become reliable only when their lifecycle is explicit. Authentication, idempotency, retries, timeouts, observability, quotas, and terminal states should be designed together rather than added after failures occur.
What you gain
- Reusable workflows separate application intent from processing infrastructure.
- Stable job identifiers and lifecycle events improve observability and recovery.
- Managed queues and workers let products scale without embedding every media tool.
What it costs
- Synchronous responses are simple but keep connections open while long work executes.
- Aggressive retries improve recovery from transient faults but can duplicate work or overload a dependency.
- Higher concurrency reduces queue time until resource contention or a downstream limit becomes the bottleneck.
Before production
- 1Define authentication, authorization, idempotency, retries, and terminal error behavior.
- 2Observe queue time, execution time, callbacks, and partial results with stable identifiers.
- 3Exercise malformed, duplicate, interrupted, and unauthorized requests before launch.