Monitoring jobs
Four views cover everything you need while work is running. Knowing which one answers your question is most of the skill.
A distributed encode has more places to go wrong than a local one, and the console is built so that each failure is visible somewhere specific rather than buried in a log. This page covers where to look.
The queue#
The queue is the list of work — one row per job, newest first. It is where you start, and for most jobs it is the only view you need.
Expanding a row opens the detail for that job: its chunk matrix, the preset that was used, and the forensic panels covering how the encode was produced. Everything about a single job is reachable from its row.
You can act on jobs from here — cancel one that is wrong, retry one that failed. Selecting several at once gives you the same actions applied to the selection, which matters when a bad watch-folder rule has just queued forty jobs you did not want.
Cancelling stops new chunks being assigned. Chunks already running on a worker finish first — the encoder is a separate process and killing it mid-write leaves a partial file. Expect a short delay between cancelling and the job settling.
The chunk matrix#
One cell per chunk, coloured by the worker that owns it. This is the product's signature view and the fastest way to tell whether distribution is doing what you think.
Each worker gets a stable colour derived from its identity, so the same machine is the same colour every time you look — across jobs, and across sessions. Once you have learned that your render box is the blue one, that knowledge keeps working.
| Cell | State | Meaning |
|---|---|---|
| Empty outline | QUEUED | Planned, not yet given to a worker. |
| Outlined in a worker colour | ASSIGNED | Handed to that worker, not yet started. |
| Solid, shimmering | RUNNING | Encoding now. The shimmer tracks progress. |
| Solid | DONE | Finished and accepted. |
| Diagonal hatch | FAILED | The encode failed. It will be retried elsewhere. |
| Dashed outline | CANCELED | Abandoned deliberately. |
Reading the matrix#
The pattern tells you more than any individual cell. Four shapes are worth recognising.
Working as intended. Every approved worker is taking chunks and finishing them at a rate proportional to its speed.
A single worker is doing everything. Either the others are not approved, or they cannot produce what this preset requires. Check the workers page — this is the most common disappointment on a new fleet, and it is a configuration problem, not a performance one.
The tail. One slow chunk on one slow worker now determines when the job finishes. Nothing is wrong; this is the fundamental limit of chunked encoding.
Chunks are failing and being retried. One or two is unremarkable — a worker went away and its work moved. A steady stream from the same worker means that machine has a real problem: a full disk, a broken accelerator, or an FFmpeg that differs from the rest of the fleet.
After the last chunk completes, the master still has to join the chunks, mux the audio back in, and verify the result. On a long source that is real time. A job showing every cell solid but not yet complete is assembling, not stuck.
The workers page#
The fleet view: every machine that has registered, what state it is in, and what it says it can do.
Check three things here when a job is not distributing the way you expect.
- Status. Only an approved, online worker receives chunks. A machine sitting in pending approval looks healthy from its own console and will never pick anything up.
- Capabilities. Each worker reports the codecs and accelerators it found. A worker missing the codec your preset needs is correctly excluded — the scheduler treats this as a hard constraint, not a preference.
- Last contact. A worker that has stopped heartbeating is on its way to offline. Its in-flight chunk will be reassigned.
This is also where you drain a machine you want to take out of service — draining stops new assignments while letting current work finish, which is the difference between a clean removal and a reassigned chunk.
The activity log#
The audit record. Every meaningful event — jobs submitted and completed, chunks assigned and failed, workers registering and being approved, verification results, preset fallbacks — lands here in order, with a live tail as things happen.
Individual events open to show their detail rather than a raw payload, so a failure tells you which chunk, which worker and what the encoder said.
This is the view that answers why. The queue tells you a job failed; the activity log tells you it failed verification because the assembled duration did not match the source. When you need to explain an outcome to someone else, this is the record.
Which view answers what#
| Question | Look at |
|---|---|
| Is it done yet? | The queue |
| Is my fleet actually being used? | The chunk matrix |
| Why is only one machine working? | The workers page |
| Why did this job fail? | The activity log |
| What settings actually produced this file? | The job's expanded detail in the queue |