Skip to main content
The published baseline values cover successful API jobs created during the 30 complete UTC days from August 18 through September 16, 2026. Three values use the latest 48-hour cohort, from September 29 at 18:00 through October 1 at 18:00 UTC, and are marked with ◎. Three values use the September 22 at 16:00 through September 24 at 16:00 UTC cohort and are marked with ※. Three values use the September 19 at 16:00 through September 21 at 16:00 UTC cohort and are marked with ◇. One value uses the September 12 at 16:00 through September 14 at 16:00 UTC cohort and is marked with ¶. Three values use the September 5 at 17:00 through September 7 at 17:00 UTC cohort and are marked with §. Two 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 October 1, 2026. A fresh 30-complete-UTC-day comparison covered September 1 through September 30, 2026; unchanged rows retain their published sample and measurement window.
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 September 19 at 16:00 through September 21 at 16:00 UTC API cohort. ※ Uses the September 22 at 16:00 through September 24 at 16:00 UTC API cohort. ◎ Uses the latest 48-hour API cohort, from September 29 at 18:00 through October 1 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 →