> ## Documentation Index > Fetch the complete documentation index at: https://docs.oasm.io/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 | 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 | 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. > [!NOTE] > > 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). > **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. ## Browse jobs in the Console The **Jobs Registry** page (route `/jobs`, open from the sidebar under **Management**) shows the registry as a table with pagination. Each row represents a scan task with its status and details. **1. Open the Jobs Registry** In the console sidebar, open **Jobs Registry** (under the **Management** section), or go directly to `/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. > [!NOTE] > > 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. > [!CAUTION] > > 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](/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 > **[Notifications](/notifications)** > > Get notified when registry tasks complete or fail > **[Worker](/worker)** > > Understand the distributed execution layer that carries out tasks > **[Groups](/group)** > > Scope workflow runs that produce the tasks you see in the registry > **[Reports](/reports)** > > Turn completed scan results into structured security reports This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.