Job Lifecycle

Every job in Rendobar follows a defined lifecycle with clear status transitions. Understanding this lifecycle helps you build reliable integrations.

Status flow

waiting → dispatched → running → complete
                                → failed
                    → cancelled
StatusMeaning
waitingJob is saved and queued for dispatch to a processing provider
dispatchedJob has been sent to the execution provider (Trigger.dev)
runningProvider has started processing the job
completeJob finished successfully — output is available
failedJob encountered an error — see error_code and error_message
cancelledJob was cancelled by the user before completion

What happens at each stage

1. Submission (→ waiting)

Your API call is validated (auth, rate limits, plan check, credit pre-check, schema validation). If all checks pass, the job is saved to the database with status waiting.

2. Dispatch (→ dispatched)

The job is routed to an available processing provider based on capabilities and load. The provider receives the job payload including presigned URLs for downloading inputs and uploading outputs.

3. Execution (→ running)

The provider downloads your input files, processes them (FFmpeg, AI detection, rendering), and uploads the result. For long-running jobs, you can monitor progress via SSE events on the dashboard.

4. Completion (→ complete)

The provider calls back to the API with the result. Credits are deducted, the job status is updated, and your webhook is fired (if configured).

5. Failure (→ failed)

If processing fails, the job is marked as failed with an error code. No credits are charged for failed jobs. Common error codes:

CodeMeaning
PROVIDER_ERRORProcessing failed on the execution provider
PROVIDER_TIMEOUTJob exceeded the maximum allowed time
VALIDATION_ERRORInput file was invalid or corrupted
DISPATCH_EXHAUSTEDJob could not be dispatched after all retry attempts

Timeouts

Each job type has a maximum execution time defined by the job registry. If a job exceeds its timeout, it is automatically marked as failed and credits are refunded.

A background cron job runs every 2 minutes to detect stuck jobs — jobs that were dispatched or started running but never reported back.

Retries

Jobs that fail during dispatch are automatically retried up to 3 times with exponential backoff. After all retry attempts are exhausted, the job moves to the dead-letter queue and is marked as failed.

You can also manually retry a failed job:

curl -X POST https://api.rendobar.com/jobs/job_abc/retry \
  -H "Authorization: Bearer rb_live_YOUR_KEY"

Webhooks

Configure a webhook URL on your organization to receive real-time notifications when jobs complete or fail. See the Webhooks documentation for details.

Real-time updates (SSE)

The dashboard connects to a Server-Sent Events stream for real-time job status updates. You can also use the SSE endpoint programmatically:

GET https://api.rendobar.com/events/connect