Clearer errors when a job times out

A job that failed for an infrastructure reason used to hand back whatever the execution backend said, which was rarely useful. A run that exceeded its time budget came back as an internal error with a platform code attached, so the one thing you needed to know, that the job was simply too long for the plan, was the one thing it did not say.

Those failures now come back in plain language, with the lever to pull:

{
  "error": {
    "code": "RUNNER_TIMEOUT",
    "message": "The job ran longer than the maximum processing time on your plan. Try a shorter input, a lower output resolution, or a faster preset."
  }
}

Out-of-memory and out-of-disk failures get the same treatment, and a job that stops unexpectedly says so rather than surfacing a signal name.

Your error codes did not change#

RUNNER_TIMEOUT and RUNNER_ERROR mean what they always meant, and anything switching on error.code keeps working. What changed is that the code is now always one of ours. Previously a backend could surface its own code, so a client could receive a value that appears nowhere in the error reference.

What still comes through untouched#

Real output from your command. When ffmpeg rejects an input or a filter graph fails to build, that text is the most useful thing the job can return, and it is passed through exactly as written. Only infrastructure failures are rewritten.

Timeouts are governed by your plan’s job time budget, listed in plan limits. A job failed with RUNNER_TIMEOUT before it started is never charged, which has always been the case and is covered in stuck jobs now fail fast.