Which Timeline warnings does the free plan call show before rendering?
Timeline plan reports gaps, tail holds, frame snaps and ignored motion, but not short sources, downgraded fades, fps resampling or soundtrack length.

The free POST /v1/timeline-1.0/plan call returns the warnings that depend only on the numbers in your document, such as gaps, a tail the video does not cover, fades that snap to whole frames and ignored motion. It cannot return anything that needs the real files, because the plan never downloads or probes media.
That split decides when to rely on the plan and when to read warnings[] on the finished render. Plan has no Idempotency-Key requirement, creates no job and reserves no credits.
What we ran and what came back
We called the repository's plan builder with a 12-second spine, a 4-second slot at 0, and a second 4-second slot at 6 seconds with a 0.3-second fade, output.fps 25. The response held coverage_seconds: 10 and three warnings: transition_snapped_to_frame, timeline_gap_filled for 2 seconds, and video_coverage_shorter_than_audio.
The same builder returned an empty warnings array for a still with source_in, a 60 fps request over unknown sources, a soundtrack with no loop, and a slot with a source_in of 50 seconds. Those need the media, so they appear only at render time.
| Warning code | Needs probed media | In the plan response | Detail |
|---|---|---|---|
| timeline_gap_filled | No | Yes | Gap between declared slots |
| video_coverage_shorter_than_audio | No | Yes | Slots end before the spine |
| transition_snapped_to_frame | No | Yes, at the plan fps | Fade rounded to whole frames |
| motion_ignored | No | Yes | motion set on a slot |
| still_source_in_ignored | Yes, to know it is an image | No | Seen at render |
| segment_source_short_padded / looped | Yes, clip length | No | Seen at render |
| transition_downgraded_to_cut | Yes, clip length | No | Seen at render |
| output_fps_resamples_sources | Yes, source frame rates | No | Seen at render |
| soundtrack_shorter_than_spine | Yes, bed length | No | Seen at render |
A pre-flight routine
Run the plan, fail your own pipeline on any warning you consider a defect, and probe the clips with video inspect for the lengths and frame rates the plan cannot see. Compare each clip's length with source_in + duration, plus the fade length on any slot that has one. Then render.
Send output.fps in the plan when you will send it in the render. With it omitted, the plan validates at 30 fps while the render matches your sources, so a frame-snap warning in the plan may differ from the render's.
Reading the render result
When the job is result_ready, GET /v1/jobs/:id/result returns kind: timeline_render with warnings[]. The documentation calls them soft warnings, not failures: padded or looped short sources, snapped transitions and ignored still motion all let the job finish. Log them with the job id so a later complaint about a frozen frame can be traced to the exact warning.
Render pricing is $0.10 per ceil output minute, and the plan response gives billable_minutes and estimated_cost_usd_micros so you can check cost in the same call.
Sources
Related posts
More in Developers
- Windmill run_wait_result vs a Sume async submit: pick one per job
Windmill advises async mode and offers run_wait_result for short jobs. Sume mirrors that split: async submit plus polling for long work, sync only for short.
- Windmill sync returns 200 on error: check Sume's failed flag too
Windmill's sync webhook returns HTTP 200 with the error as JSON by default. Do not trust the status code alone for Sume jobs: read terminal, failed and sync.
- Crash-safe Sume submit: write the intent row and key first
If your process dies after a Sume submit but before storing the job id, a pre-written intent row and Idempotency-Key let the retry return the original job.
- YouTube Analytics creatorContentType: split Shorts from long-form
The creatorContentType dimension separates SHORTS from VIDEO_ON_DEMAND in YouTube Analytics API reports. How to use it on clips you generated with Sume.
Written by Sume