The Video Transcoding page in my.cubepath.com lists every job with its source, outputs, destination, status and creation time. While anything is still running the list refreshes itself every few seconds, so you can leave it open and watch the queue drain.
The lifecycle
| Status | What's happening |
|---|---|
| Queued | Accepted, waiting for a worker. Normal under load |
| Analyzing | We're reading the source to work out its duration, streams and how to segment it |
| Encoding | The renditions are being produced, in parallel across segments. This is where the time goes |
| Finalizing | Segments are being stitched, packaged and uploaded to your bucket |
| Completed | Every output is written to the destination |
| Failed | Something stopped it. The error is on the job |
| Canceled | You cancelled it before it finished |
The first four are transient; the last three are final. A job in a final state never changes again.
Progress and segments
A running job carries a 0–100 progress number and, once it's past analysis, a completed / total segments counter. The segment counter is the more honest of the two on long files: it tells you how much of the source has actually been encoded, and it moves in visible steps.
Use the status filter above the list to narrow it to what you care about — usually failed when something's wrong, or encoding when you want to know what's occupying capacity right now.
Getting the outputs
When a job completes, View outputs lists every file it wrote, with its bucket and key. It's the quickest way to confirm the paths are what you expected before you point an application at them; the files themselves are in your own bucket, so you fetch them from there.
If nothing is listed on a completed job, the outputs produced no artifacts — an HLS output with no rungs is the usual culprit. See Outputs.
Webhooks
Set a webhook URL when you create the job and we POST to it when the job reaches a final state. That's the right way to drive a pipeline: no polling loop, no waiting.
NoteWebhook delivery is best-effort and not retried. Treat it as a nudge, not a guarantee — when the notification is what triggers publishing, have a sweep that reconciles anything still marked in-flight against the job status, and you'll never lose a video to a dropped request.
Cancelling and deleting
Cancel stops work that hasn't been done yet and removes the job's pending tasks. A job that already completed or failed can't be cancelled — there's nothing left to stop. Cancelling doesn't delete anything already written to your bucket; if the job got as far as uploading, those files stay and are yours to clean up.
Delete removes the job from the list. It doesn't touch your bucket either.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| Stuck on queued | Normal under load; encoding starts as capacity frees up. If it never moves, check whether you're at the active-jobs cap in Batches and limits |
| Failed immediately | The source couldn't be read — a URL that 404s, an object key that doesn't exist, or credentials that can't read it |
| Failed at the end | The destination rejected the write: wrong endpoint, wrong region, or a key without write permission on the prefix |
| Completed with no outputs | An HLS output with no rungs, or an output list that produced no artifacts |
| Progress moves then stalls | A very large file or an expensive ladder — 4K and h265/av1 encode slowly. Check the segment counter; if it's still climbing, it's working |
| No webhook arrived | Delivery isn't retried. Confirm the endpoint is reachable and returns quickly, and reconcile from the job status |
TipView error on a failed job shows the message the encoder actually produced. Read it before you change anything — it names the stage that failed, which is nearly always enough to tell a source problem from a destination one.