How Often Do AI Video Generations Actually Fail? Provider Errors and Moderation Refusals Across 498 Real Runs

Data window: 2026-05-06 to 2026-08-22 · Last updated: 2026-08-23

The short answer

Across 498 video generations on a multi-model platform between 6 May and 22 August 2026, provider-side failures were rare on four of six models, sitting between 0% and 1.4%. Two supplier routes were far worse: one at 36.2%, and an image-model route outside this table at 17.0% (9 of 53). Content-moderation refusals ran from 0% to 26.0% depending on the model, and 31 of the 47 refusals named a real human face in a reference image. Every rate below carries a 95% confidence interval, and the rules used to classify each failure are published in full.

Two kinds of failure

Three different events send someone back to regenerate a shot. Only two of them leave a trace a log can count:

1. The generation broke. A timeout, a provider error, a queue failure. Nothing came back.
2. Content moderation refused it. The model worked and its content policy declined the request.
3. It completed and was not what the person wanted. Technically a success. The record is identical to a keeper.

This article measures the first two. The third is out of scope and not measurable from logs: nothing distinguishes a discarded generation from a kept one. Published estimates of how many attempts a usable shot takes exist, but they are either illustrative assumptions or single-production case studies, not controlled measurements, so no share is inferred for the third category here.

The two have different causes: breakage comes from the supplier route, while a refusal comes from content policy meeting whatever was submitted to it.

The data

Six video models cleared 30 valid runs in the window. Image models are excluded entirely; mixing them in would answer a question about video with data about something else. An earlier post covers the image models on a wider but less carefully bounded cut of the same log.

ByteDance publishes no "Pro" tier; resellers use the label for the standard Seedance 2.0 endpoint, which is what the row above measures.

Parentheses are 95% Wilson confidence intervals. Two readings follow from them that the point estimates alone would not support.

How every failure was classified

Source: the platform's generation log, filtered to video-type rows created between 2026-05-06 and 2026-08-22 inclusive. Each row was assigned exactly one class, matched in this order:

ok       : status = 'completed'

refused  : error_message ~* '(may contain real person|inappropriate
           content|celebrity|involving minors|copyright restrict|
           watermark|AUDIO_FILTERED|content security audit)'

ourside  : error_message ~* '(Insufficient corporate funds|balance is
           insufficient|validation failed|only supports|Invalid
           parameters|Parameter validation|input.prompt: size|Error
           validating image|style reference must be|iw )'

broke    : every other failed row

The ourside class is removed from the denominator because those failures measure our integration rather than the model: account-level problems upstream, and requests our own code malformed. Excluded counts appear per model in the table above so the correction stays visible in the totals. Seedance 2.0 Mini shows why this matters, with 32 of 82 raw failures excluded; uncorrected it reads as a 39% failure rate, corrected it is 0% on 50 valid runs.

Output-side audio filters (AUDIO_FILTERED, content security audit) sit under refused because a user experiences them the same way as any other policy block. They account for 15 of the 47 refusals.

One boundary decision changes a headline number: generic upstream messages such as Operation failed. Please retry. and An error occurred. carry no attribution. They are counted as broke, not excluded. Grok Imagine reads 36.2% under that rule and 16.1% if those messages are set aside instead. The higher figure is reported because attributing an unexplained failure to the supplier rather than to ourselves is the conservative choice when the supplier is the one being measured.

What triggers a refusal

Forty-seven video generations were refused across all video models in this window: 42 on the six models in the table, the other five on models below the 30-run threshold. Grouped by the message the provider returned:

• 31 · a real person in a reference image. Returned as "The request failed because the input image may contain real person."
• 11 · copyright or audio rights. Content security audits on generated or referenced audio.
• 4 · audio filtered on models that generate sound natively.
• 1 · explicit or suggestive material.

Two thirds of all refusals come from one cause. The filter reads the reference image, not the prompt, which is why rewording rarely helps and swapping a photograph of a real person for a generated character usually does.

The log does not record whether a run carried a reference image, so the table has no column for the workload behind each rate. One measurement stands in for it: none of the 145 Grok Imagine runs in this window carried an image parameter or a bound character, so its 0% refusal rate reflects a text-only workload and not a permissive filter. All 31 real-person refusals landed on the Seedance family, 20 on Seedance 2.0 and 11 on Seedance 2.0 Fast.

The two outliers are our routing

Grok Imagine's 36.2% measures the supplier route, not the model. Every generation on this platform reaches its model through such a route, and that route is what a provider-side failure measures: timeouts, upstream errors, capacity problems at the intermediary. A different platform routing the same model differently would produce a different number.

The same applies to the second high-failure route in this data, an image model outside the table. Both figures were what prompted a review of those routes. They belong in a section about infrastructure, and they should not be read as evidence about model quality.

Refusal rates carry further, with one caveat. A refusal carrying the model provider's own error string, as these 31 do, reflects that provider's policy and should recur on other routes to the same endpoint. Intermediaries can add stricter filters of their own: RunningHub, for example, enforces a platform-level real-person block regardless of model. Treat these rates as a floor.

What this does not tell you

• It measures refusals and breakage, not quality. A generation that completed and looked wrong counts here as a success, and that category is likely the largest source of regeneration in practice.
• Sample sizes are small and uneven. Six models cleared the threshold; 148 runs and 35 runs are not the same weight of evidence, which is why every cell carries its interval.
• Refusal rates reflect what our users submitted. An audience working with different source material would produce different rates on the same models.
• Refusal rates are confounded by workload. The table does not show how many runs per model carried a real-person reference image. If one model receives more photo uploads than another, it inherits more refusals regardless of policy strictness.
• Supplier routes changed during the window. Provider-side failure rates are a measurement of a moment, and the two high figures above are precisely the ones that triggered changes.
• Content filters move without notice. Model providers adjust thresholds continuously and rarely announce it, so refusal rates drift.