​
Overview

A job is one asynchronous operation the platform is carrying out on your behalf — creating a machine, attaching a volume, building a VPC. This screen is where you find out whether your last action actually finished.
Navigation: Monitor → Jobs. Titled Jobs, subtitled “Async job queue”.
This is the first place to look when something you did seems not to have taken effect. Almost every “it didn’t work” turns out to be either a job still running or a job that failed with a specific reason printed right on the row.

​
Stat cards

Total, Running, Completed, and Failed, scoped to your selected time window.
These counts come from a separate aggregate query over the whole time window, not from the page of rows you’re looking at. So Total can legitimately read 400 while the table shows 20 rows.

​
Columns

The row menu has one item: Copy Job ID.

​
Statuses

The platform reports more states than these four, and the collapse has one consequence worth knowing: work the backend calls PENDING displays as Running, because the platform already considers it in flight. Only genuinely queued work shows as Pending.So a job showing Running may not have started executing yet. Don’t infer progress from the badge alone — use Duration.

​
Filters

Search matches job content, with a short debounce.
The 6h default is the single most common reason a job “doesn’t exist”. A failure from yesterday morning simply isn’t in the window. Widen to 7d or All before concluding a job was never created.
Everything here filters on the server — search, status, type, time window, and pagination all go to the platform, and only the current page is held in the browser. That’s the opposite of Events, and it means Jobs stays accurate no matter how much history you have.

​
Live updates

Rows update as job statuses change. The behaviour is deliberately conservative: on page 1 with no filters, a changed row is patched in place. If you have any filter set or you’re on a later page, the whole query re-runs instead — so a job that changes status can’t get stranded in a result set it no longer belongs to.

​
Reading a failure

Never retry a create because it timed out. The console stops watching a single job after about two minutes and reports a timeout, but the job keeps running on the platform. Retrying at that point is how you end up with two machines and double the quota consumed.Check the job’s real status here first. “Timed out” in a dialog means “we stopped watching”, not “it failed”.

​
Worked example: a VM that never appeared

1

Set the window wider than the default

Change the time window from 6h to 24h. The default window is narrow enough to hide a morning failure by the afternoon.
2

Narrow to the right kind of work

Set the type filter to VMs so volume and network jobs don’t crowd the list.
3

Filter to Failed

If nothing is Failed, check Running — a large machine can take a while, and the answer is patience rather than action.
4

Read the error on the row

The red text under the job name is the platform’s own reason. Common ones are quota ceilings and insufficient capacity in the chosen zone.
5

Act on what it says

A quota error means reclaiming or requesting more — see Quotas and limits. A capacity error means trying another zone. Anything unclear: Copy Job ID and send it to support, since that ID lets them find the exact operation.

​
Empty and error states

Events

The durable audit trail, as opposed to live work.

Jobs and events

Which screen answers which question.

Quotas and limits

The most common cause of a failed job.