Render reliability and failed-frame recovery in Q3 2026
By Superluminal Engineering
A forthcoming look at completed frames, failures, retries, recovery, and the causes behind interrupted Blender renders.
Published 2026-07-29 · Updated 2026-07-29
Publication status
This is the preregistration for a Q3 2026 reliability report. The quarter is still open on 2026-07-29, so the page is noindex and publishes no success rate. A reliability percentage without an eligible denominator, attempt rules, attribution, and uncertainty would be advertising rather than useful operational evidence.
Unit of analysis
The report will distinguish a job, a requested frame, an execution attempt, and a delivered output. One frame can have multiple attempts after a retry or requeue, while the artist ultimately cares whether a valid output became available. Both views matter:
- attempt reliability describes operational work and recoveries;
- frame outcome describes the requested deliverable;
- job outcome describes whether the requested job completed within the declared window; and
- recovery time describes how long an interruption affected delivery.
Stale or duplicate events cannot simply disappear. The analysis must identify their cause, suppress them from changing the authoritative final state where appropriate, and retain them in the operational ledger.
Failure taxonomy
| Attribution | Examples | Publication treatment |
|---|---|---|
| Customer input | Invalid scene, settings, missing or incompatible asset | Included and labeled |
| Blender or add-on runtime | Crash, unsupported API, deterministic render error | Included and labeled |
| Farm infrastructure | Node, storage, network, scheduling, orchestration | Included and labeled |
| Recovered transient | An interruption followed by valid output | Count event and final recovery |
| Unknown | Insufficient or conflicting evidence | Keep visible; never force into a favorable bucket |
A retry does not erase the original failure. A recovered frame should contribute to both the interruption count and the recovered final-outcome count.
How render interruptions are grouped
Failures and recovered events are grouped by where they happened and how the job returned to useful output.
| Criterion | Examples | Retry counted | Final outcome retained | Status |
|---|---|---|---|---|
| Customer input | Scene, settings, missing or incompatible asset | Yes | Yes | Definition pending review |
| Blender or add-on runtime | Crash, unsupported API, deterministic render error | Yes | Yes | Definition pending review |
| Farm infrastructure | Node, storage, network, orchestration | Yes | Yes | Definition pending review |
| Recovered transient | Retry or requeue reaches a valid final output | Yes | Yes | Definition pending review |
| Unknown | Unknown or conflicting events | Yes | Yes | Must remain visible |
Denominator and privacy rules
Before extraction, the owner must freeze the reporting window, eligible production traffic, treatment of internal tests, canceled jobs, duplicate requests, manually intervened jobs, and incomplete observation. Missing telemetry remains missing; it is not silently converted into success.
Public tables use privacy-safe aggregates. Customer names, scene names, filenames, private paths, job identifiers, credentials, raw logs, and small identifying cohorts are prohibited. If a cohort cannot meet a safe threshold, it is merged into a broader group or suppressed while the denominator remains explainable.
Required outputs
The final report should publish the eligible jobs and frames, attempts, failures by cause, recovered outcomes, unrecovered outcomes, retry distribution, recovery-time distribution, unknown share, exclusions, missing-data rate, and uncertainty. Billing treatment must be described from an independently validated contract rather than inferred from status labels.
The persistent-overhead study will explain where time is spent; it must not be mixed into reliability unless the event taxonomy supports the connection. The Blender 5.1 benchmark is a controlled fixture study, while this report is an observational production cohort. Their denominators stay separate.
From job events to the Q3 reliability report
- Now · Freeze taxonomy and denominator
Define eligible jobs, frames, attempts, retries, stale events, attribution, and privacy thresholds before reading the result.
- Quarter close · Close the observation window
Do not publish a Q3 rate while the reporting period is incomplete.
- Analysis · Reconcile attempts and final outcomes
Keep recovered failures, suppressed stale attempts, retries, and unresolved cases visible.
- Review · Privacy and methods review
Apply cohort thresholds, remove customer-identifying details, verify billing language, and independently review the analysis.
- Publish · Release numerator, denominator, uncertainty, and code
Only then may the page become indexable and state a bounded reliability result.
Release gate
After the quarter closes, the event ledger must be reconciled, analysis code versioned, privacy reviewed, and methods independently checked. Only then may the page become indexable and state a bounded result. Claims such as “99.9% reliable,” “never loses frames,” or “all failures are retried” remain blocked unless the published evidence directly supports that exact scope.