Agent Jobs

Every operation the panel performs on a hypervisor is a job. The panel never talks to a machine directly: it writes an instruction, the node's agent collects it over an outbound connection, carries it out and reports back. The Jobs screen is that queue. When something "did not happen", the answer is always here — whether the job was ever collected, how long it ran, and what the agent said when it failed.

Opening the page

Open VPS in the admin sidebar, then the Jobs tab. The header reads Agent Jobs — Every VM operation this panel sent to a hypervisor agent. A refresh control sits beside it.

Note: this screen is read-only, and it deliberately does not show what a job contained. Job contents can carry credentials — the password of a panel being imported, or the first-boot password of a new machine — so they are never served to the browser. You see what the operation was, where it ran, how it went and any error text.

What is on the page

Summary

Four figures across the top: In flight, Queued, Completed 24h and Failed 24h. The failure count turns red when it is not zero. These same figures appear on the module's Overview tab, where a non-zero failure count is raised as an alert.

Filters

Three dropdowns: All statuses, All clusters and All job types. The job-type list only contains types that actually appear in your history.

Columns

Columns in the job table

Column	What it shows
Job	The operation, and underneath it the machine it was about, if any. The machine name can be copied with a click.
Status	See the table below.
Cluster	The node it ran on, linked to that cluster. Jobs not tied to a cluster show the agent instead.
Duration	How long it ran.
Created	When it was queued. Today's jobs show a time; older ones show a date and time.
Detail	The agent's error text, which can be copied with a click. A job still waiting reads Waiting for the agent to claim it.

Job states

The states a job moves through

State	Meaning
Queued	Written by the panel, not yet collected. Agents check for work every few seconds, and the panel nudges the agent as soon as it writes a job, so this state normally lasts moments.
Claimed	The agent has taken it and is starting.
Running	In progress.
Completed	The agent finished and reported success.
Failed	The agent tried and reported an error. The reason is in the Detail column.
Timed out	The job passed its deadline without finishing or without reporting progress.
Cancelled	Stopped before it completed.

What the operations are

A machine's own Activity section names these in plain words; the Jobs list spells them more tersely, but they are the same operations.

• Create VM — build a machine: create its disks, seed them from an image, write the first-boot configuration and start it.
• Power action — start, shutdown, reboot, pause, resume or hard power off.
• Reconfigure VM — change cores, memory or disk size.
• Delete VM — remove a machine, with or without wiping its disk.
• Reinstall OS — overwrite the operating-system disk from an image.
• Inventory refresh — re-read what is on a node.
• Live migration — move a running machine to another node in the same group.
• Snapshot — take, revert or delete a snapshot.
• Apply resource limits — write CPU, network and disk ceilings onto a machine.
• ISO and boot order — attach or eject media, and change what a machine boots from.
• Read the guest agent — ask a machine about itself from the inside.
• Reset guest password.
• Apply network filter — attach the anti-spoofing filter to machines on a node.
• Convert to libvirt — finish adopting a machine that came from a panel managing guests its own way.
• SSH key mesh — distribute the access keys that make live migration inside a group possible.
• Panel discovery, Adopt VMs and Remove the old panel — the import steps described in VPS Panel Migration.
• Command on the node — a maintenance command run on the machine itself.

How long a job is given

Each kind of operation carries its own deadline, because a single deadline would be wrong for all of them. Reading an inventory is a matter of seconds; streaming a large disk to another node can legitimately run for hours. A migration of local disks is given the longest budget of all; building or reinstalling a machine is given an hour; a power action several minutes.

A job that keeps reporting progress keeps its deadline moving. A long build with an image still downloading is not timed out for being slow — it is timed out only when it goes quiet.

What a stuck or failed job means

Stuck at Queued

Nothing has collected it. Almost always the agent: check the cluster's status on the Clusters page, and check the agent under Local Agents. An unreachable cluster leaves its jobs queued until the agent reconnects, at which point they are collected and run in order. Nothing is lost by an agent being offline for a while — jobs are picked up when it comes back, until they pass their deadline.

Stuck at Running

The agent has it. Long operations belong here: a build downloading a large image, a reinstall, a migration copying disks. Look at the Duration column and compare it with the kind of operation. The panel checks the queue every 5 minutes and closes out anything genuinely abandoned, marking it Timed out.

Failed

The agent tried and could not. The Detail column carries the agent's own message; copy it before you go looking. Frequent causes:

• Not enough space in the storage pool the machine was to be built in.
• A bridge or storage pool named on a plan or a product that does not exist on the chosen node.
• An operation that needs the guest agent — a password reset, or reading the guest — on a machine that does not have it running.
• A migration where the wrong storage mode was chosen for how the node's storage is actually set up.
• A licensing problem on the node: a cluster only runs virtual-machine work while it holds a valid certificate. Registering a cluster requests one immediately, and a node that has just come back after a long outage may briefly refuse work until a fresh one arrives.

Timed out

The job passed its deadline with no progress reported. Verify on the node what actually happened before you repeat the operation — the panel closes the job out, but it cannot know how far the agent got.

How retries behave

There is no blanket automatic retry of agent jobs, and that is deliberate: silently repeating a half-finished disk operation is worse than stopping. What does happen:

• Collection is retried, not the work. A queued job waits for the agent as long as its deadline allows. It is not lost by an agent restart, an agent update, or a short outage.
• Sold machines whose build failed are retried automatically. A service left in a failed provisioning state is retried up to three times, waiting 1, then 5, then 15 minutes between attempts. After that it is left alone for a person to look at, so nothing loops forever on an unrecoverable fault. See Service Details for the manual retry.
• Builds whose completion never arrived are settled. If an agent finishes a build but the confirmation does not reach the panel, a sweep every 5 minutes finds the completed job, activates the service and sends the credentials, so a paid machine is not left looking unbuilt.
• Deletions are settled the same way, so a machine whose removal outran the panel's wait is closed out and its addresses released rather than left in limbo.
• Bulk power actions offer a manual retry. After a bulk action, Select the ones that failed re-selects exactly those machines so you can send the action again.
• Everything else is repeated by you, from the machine or the cluster it belongs to.

Warning: before repeating a failed build or delete, check the node. A job that failed late may have left disks behind, and repeating it blindly is how the same machine ends up built twice.

How long history is kept

Finished jobs — completed, failed, timed out or cancelled — are purged after a number of days you set in VPS Settings under Agent job history (three days by default, and it can never be set to zero). Job records hold large result payloads, so this window is what stops the history from filling your disk. A machine's Activity section is subject to the same window, which is why an old machine can show nothing at all.

Tip: if you need to keep the detail of a failure, copy the error text out of the Detail column before the window passes. It is not archived anywhere else.

Where to go next

• Clusters — the node a failing job runs on.
• Virtual Machines — the per-machine Activity section, which shows the same jobs in plain words.
• Local Agents — the agent's own status and install log.