Skip to main content
The refreshed baseline comparison covers successful API jobs created during the 30 complete UTC days from August 18 through September 16, 2026. One value uses the latest 48-hour cohort, from September 15 at 18:00 through September 17 at 18:00 UTC, and is marked with ※. Two values use the September 12 at 16:00 through September 14 at 16:00 UTC cohort and are marked with ¶. Five values use the September 5 at 17:00 through September 7 at 17:00 UTC cohort and are marked with §. Four unchanged values use the September 4 at 01:00 through September 6 at 01:00 UTC cohort and are marked with ‡. Unmarked rows retain their published baseline value and sample. All values measure end-to-end time from project creation to completion, including queueing. The warehouse snapshot was queried on September 17, 2026.
These are directional observations, not an SLA or a prediction for an individual job. Processing time varies with the endpoint, selected model and settings, input duration and size, output resolution, and current queue load. Build timeout handling into every integration.
Typical (p50) means half of successful jobs finished within this time. Sample is the number of successful API jobs included. Errored, canceled, and still-active jobs are excluded.
These metrics are reviewed twice weekly. If the end of the measurement window is more than seven days old, treat the figures as historical until the next refresh.

​
Video endpoints

† Fewer than 30 successful jobs. Treat these figures as low-confidence until more traffic is available. ‡ Uses the prior 48-hour API cohort, from September 4 at 01:00 through September 6 at 01:00 UTC. § Uses an earlier 48-hour API cohort, from September 5 at 17:00 through September 7 at 17:00 UTC, because its median was faster than the value published before that refresh. ¶ Uses the September 12 at 16:00 through September 14 at 16:00 UTC cohort, because its median was faster than the currently published value. Other rows retain their published baseline or earlier 48-hour value. ※ Uses the latest 48-hour API cohort, from September 15 at 18:00 through September 17 at 18:00 UTC, because its median was faster than the currently published value. Other rows retain their published baseline or earlier 48-hour value.

​
Image endpoints

​
Audio endpoints

​
Monitor every job

After creating a job, store its project ID and monitor the corresponding image, video, or audio project until it reaches a terminal status.
  • Prefer webhooks for production and higher-volume integrations.
  • If polling, use exponential backoff instead of a tight fixed interval.
  • Handle complete, error, and canceled explicitly. Continue waiting while a job is queued or rendering.
  • Make webhook handlers idempotent and verify every webhook signature.

​
Choose timeouts for your product

Do not use a typical time as a failure threshold. Set a user-facing timeout based on your product’s tolerance for delayed work. Reaching that timeout should stop or defer your own waiting flow; it does not prove the Magic Hour job failed. Keep the project ID so you can check the final status later. Longer inputs, higher resolutions, and more complex video workflows generally need more time than small image jobs. Test the exact endpoints, models, settings, and input ranges your integration will use before choosing retry and timeout behavior.

​
Investigate an unusually long job

  1. Retrieve the project again and check its current status and error details.
  2. Confirm the input file is valid and the account has enough credits.
  3. Avoid submitting duplicate jobs while the original is still active.
  4. If the job remains active beyond your workload-specific timeout, contact support with the project ID, endpoint, creation time, current status, and non-sensitive input details.
Learn how to monitor jobs and handle errors →