Understand render statuses: In Queue, In Progress, completed, failed, retrying
Learn what each render status means and why retrying and multiple attempts are normal automatic recovery rather than a broken render.
Every render moves through a fixed set of states. HD renders may additionally be placed in a waiting state when the free HD render queue is full; such renders are held and automatically promoted to render once a slot becomes available, and a render can also be cancelled.
When the user fires a render it is created as 'initialized', shown in the render gallery as "In Queue" with a queue rank. If the free HD render slot is currently busy, the render may instead be created as 'on_hold' and shown as waiting, with an estimated rank, until the slot frees up.
A queued render normally stays in line until it is processed; it does not expire just from waiting.
With fair-use HD rendering, a user may have at most one free HD render in the queue at a time. Any extra HD renders are placed on hold rather than queued, and are promoted automatically into the queue as the slot frees up. A held render that is promoted but never actually starts can be failed automatically after a timeout so the slot is freed.
The rendering pipeline retries automatically. Each try is recorded as a separate Render_Attempt with its own serial number, its own info and error log files, and its own finished timestamp; the render record carries an attempts counter. A render in 'retrying' status has simply been put back in the queue after a failed attempt — it keeps its exact parameters, still occupies its place in the queue, and will produce the intended image when an attempt succeeds; renders routinely complete on a second or third attempt. Nothing is charged for failed tries: billing counts one completed render regardless of how many attempts it took. What to tell a client: leave it alone, retrying resolves itself in the normal queue flow. When to dig deeper: if a render bounces between retrying and queued for many hours, or accumulates a large attempts count, that points either to the design consistently crashing the renderer (the per-attempt error logs will show it) or to no rendering workers running (see the stuck-queue knowledge). The enterprise APIs get_all_of_design and get_by_id return render_attempts inline, including each attempt's log paths, so engineering can diagnose a specific render without reproducing it.