Skip to main content
The Job Registry is the central activity log of every scan, discovery, and execution task across the workspace. Whenever a workflow 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, and the Job Registry is where that activity becomes visible and manageable.

​
Key concepts

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:
1

Queued

The task is started and waits for an available worker. Tasks at this stage consume no compute.
2

Running

A connected worker picked up the task and is carrying it out. The task stays here until it produces a result or fails.
3

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.
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.
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.

​
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.
1

Open Management → Jobs Registry

Navigate to the Jobs Registry page (/jobs).
2

Browse the table

The table lists tasks with pagination. Use the controls to page through runs.
3

Open a job

Click a row to open the task detail page at /jobs/runs/{id}.

​
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).
1

Open the job detail page

Navigate to /jobs/runs/{id} for the failed task.
2

Click re-run

Use the re-run action to start the task again.
3

Watch the new run

The re-run appears in the registry and moves through Queued, Running, and then Completed or Failed.
Everything available in the console is also available through the API — see the API Reference tab.

​
Cancel a job

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

Open the job detail page

Navigate to /jobs/runs/{id} for the task you want to stop.
2

Click cancel

Use the cancel action.
3

Confirm the status change

The task is marked Cancelled and stops consuming worker capacity.
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.

​
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.
  • 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.

Notifications

Get notified when registry tasks complete or fail

Worker

Understand the distributed execution layer that carries out tasks

Groups

Scope workflow runs that produce the tasks you see in the registry

Reports

Turn completed scan results into structured security reports