> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oasm.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Job Registry

> Central registry of every scan, discovery, and execution job across the workspace

The **Job Registry** is the central activity log of every scan, discovery, and execution task across the workspace. Whenever a [workflow](/jobs) runs or a discovery is triggered, the scan tasks it produces are recorded here — giving you visibility into what workers are doing right now and a full history you can act on with re-runs and cancellations.

Because OASM runs scans on separate worker machines, scan tasks do not run inside the core system. They are started and carried out by connected [workers](/worker), and the Job Registry is where that activity becomes visible and manageable.

## Key concepts

<Table>
  | Concept     | Description                                                   |
  | ----------- | ------------------------------------------------------------- |
  | Job         | One scan or discovery task, carried out by a worker           |
  | Job history | A record of a run: which tasks it produced and their outcomes |
  | Run type    | How the task was triggered — manually or on a schedule        |
  | Priority    | Numeric priority of a task; lower values are higher priority  |
</Table>

Jobs are grouped by the kind of work being performed: subdomain discovery, HTTP service probing, port scanning, vulnerability scanning, screenshot capture, classification of technologies and services, and assistant-driven analysis.

## Job lifecycle

A scan task moves through a clear lifecycle from the moment it is started:

<Steps>
  <Step title="Queued">
    The task is started and waits for an available worker. Tasks at this stage consume no compute.
  </Step>

  <Step title="Running">
    A connected worker picked up the task and is carrying it out. The task stays here until it produces a result or fails.
  </Step>

  <Step title="Finished">
    The task ends as **Completed**, **Failed**, or **Cancelled**. Completed tasks add their results to your inventory; failed tasks can be re-run; cancelled tasks were stopped by an operator before completion.
  </Step>
</Steps>

<Info>
  A task only leaves the Queued stage when a connected worker picks it up. If tasks stay Queued for a long time, check that workers are connected and healthy — see [Worker](/worker).
</Info>

<Accordion title="What is the skipped status?">
  Some API responses expose an additional status — Skipped — for tasks that were bypassed or superseded during a run (for example, because a preceding step failed). For everyday operations the states above are the ones you manage; skipped tasks are informational.
</Accordion>

## Browse jobs in the Console

The **Jobs Registry** page (under **Management → Jobs Registry**, route `/jobs`) shows the registry as a table with pagination. Each row represents a scan task with its status and details.

<Steps>
  <Step title="Open Management → Jobs Registry">
    Navigate to the Jobs Registry page (`/jobs`).
  </Step>

  <Step title="Browse the table">
    The table lists tasks with pagination. Use the controls to page through runs.
  </Step>

  <Step title="Open a job">
    Click a row to open the task detail page at `/jobs/runs/{id}`.
  </Step>
</Steps>

## Inspect a job run

The task detail page shows everything about a single run — which workflow or discovery produced it, its category, status, and outcome. From here you can act on the task.

## Re-run a job

Failed tasks are meant to be retried — the operation that failed often succeeds once transient conditions change (a worker came back, a target was reachable again, a tool was reconfigured).

<Steps>
  <Step title="Open the job detail page">
    Navigate to `/jobs/runs/{id}` for the failed task.
  </Step>

  <Step title="Click re-run">
    Use the **re-run** action to start the task again.
  </Step>

  <Step title="Watch the new run">
    The re-run appears in the registry and moves through Queued, Running, and then Completed or Failed.
  </Step>
</Steps>

<Info>
  Everything available in the console is also available through the API — see the API Reference tab.
</Info>

## Cancel a job

Stuck, unwanted, or superseded tasks can be cancelled to free worker capacity and keep the registry clean.

<Steps>
  <Step title="Open the job detail page">
    Navigate to `/jobs/runs/{id}` for the task you want to stop.
  </Step>

  <Step title="Click cancel">
    Use the **cancel** action.
  </Step>

  <Step title="Confirm the status change">
    The task is marked Cancelled and stops consuming worker capacity.
  </Step>
</Steps>

<Danger>
  Cancelling a task stops it before completion — its results are not added to your inventory. Cancel only tasks you intend to discard or replace with a re-run.
</Danger>

## Best practices

* **Check the registry after every workflow run.** Confirm tasks finish; a run that started nothing, or tasks stuck Queued, means the workflow or the worker layer needs attention — see [Workflows](/jobs).
* **Re-run failed tasks promptly.** Transient failures are the most common cause; a re-run is cheaper than investigating an empty result.
* **Cancel stuck tasks.** Tasks stuck Running block capacity and usually indicate a dead or disconnected worker — cancel and re-run after restoring the worker.
* **Use status filters for triage.** Filter Failed for the day's remediation queue and Running to verify the execution layer is actually working.
* **Match worker capacity to demand.** A persistent Queued backlog means too few workers for the workload — scale horizontally, see [Worker](/worker).

## Related

<Card icon="bell" title="Notifications" horizontal href="/notifications">
  Get notified when registry tasks complete or fail
</Card>

<Card icon="cpu" title="Worker" horizontal href="/worker">
  Understand the distributed execution layer that carries out tasks
</Card>

<Card icon="users" title="Groups" horizontal href="/group">
  Scope workflow runs that produce the tasks you see in the registry
</Card>

<Card icon="file-text" title="Reports" horizontal href="/reports">
  Turn completed scan results into structured security reports
</Card>