> ## Documentation Index > Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Managing Jobs > Watch jobs across three lists, read job details, pause or rerun jobs, or follow up a failed scan. Every job that has been created runs according to its schedule. The lists below show the whole stock by status, and one shared detail sidebar supplies the particulars along with the tools to intervene. ## The three lists | List | Shows | Sorted by | | - | - | - | | *Active* | everything that will still do something – running now or with a next date | *Next Execution* | | *Completed* | executed jobs with result, duration and number of assets | *Ended*, newest first | | *Failed* | failed jobs | *Ended*, newest first | *Active* shows more than just running jobs: a completed job stays visible there as long as its schedule is active and a next date is set. A job executed once without a schedule, on the other hand, disappears from *Active* after it runs – you then find it only under *Completed* or *Failed*. The *Last result* column carries the same name and the same value in all three lists: a job with *Failed* still stays active and runs again at its next date. In the *Active* list, the *Next Execution* column shows *Paused* while the schedule is inactive — instead of a next date. ## Keeping an eye on running scans The *Active Scans* section on the dashboard names the running jobs with their name, module and running time; *Show More Active Scans* jumps to *Scan › Active* with the *Running* filter set. From there, as from the job detail, *Stop* ends a running execution after a confirmation. ## Reading the job detail Clicking a row opens the same sidebar in all three lists, with the job name, module, schedule and gateway in its header. As long as the job is running, the *Running* badge stands next to it. Below that follow five sections: 1. **Metrics of the last scan** – *Errors*, *Assets* and *Duration*; appears only once at least one of the three values is available. 2. **Last Scan Details** – every result of the last execution, not just errors, searchable through the *Filter…* field. From here, *Open Gateway Protocol* leads straight into the [Diagnostics](/docs/en/scan/gateway#diagnostics) of the associated gateway. 3. **Next Execution** – the next date, if one is set. 4. **Execution History** – a timeline of past executions with time, duration and result. 5. **Configuration** – job name, module, schedule, gateway and gateway status; *Show Configuration* opens the same summary the wizard showed in its last step. *Succeeded (No Data)* means: executed, but without a result – usually a sign about the targets or the rights of the credential used. *Failed (with data)* means: data was already captured despite the abort. All values are in the [Scan Reference](/docs/en/scan/reference#results-in-the-execution-history). ## Actions on a job | Action | Available when | Effect | | - | - | - | | *Stop* | job is starting or running, not waiting for processing, gateway connected | aborts the execution | | *Pause* | schedule active, gateway connected | deactivates the schedule | | *Resume* | schedule inactive, gateway connected | activates the schedule again | | *Run Now* | no execution open, not waiting for processing, gateway connected, no one-time credentials | starts the job immediately | | *Edit* | always | opens the wizard with the stored values | | *Delete* | always | removes the job after a confirmation | With the module access *Viewer* the bar with the actions is missing entirely; the other sections of the job detail stay readable. If the gateway is **offline**, *Stop*, *Pause*, *Resume* and *Run Now* disappear from the sidebar; only *Edit* and *Delete* remain. In that case check the [gateway](/docs/en/scan/gateway#reading-the-overview) first, not the job. A job with **one-time credentials** does not show *Run Now* at all: the access data was not saved and has to be entered afresh through *Edit* before the job can run again. When **editing** an older job, the *Schedule* step can hold you up: if the *Start* once set now lies in the past, the date field demands a correction before the wizard moves on. See [Creating a Scan Job](/docs/en/scan/create-inventory#setting-the-schedule). ## Pausing instead of deleting a job *Pause* only sets the schedule to inactive – the complete configuration stays intact, and *Resume* restores it at any time. *Delete*, by contrast, removes the job for good; the configuration cannot be recovered afterwards. Use *Pause* for maintenance windows, relocations or a temporarily missing target, and delete a job only once its source falls away for good. As long as a next date is set, a paused job stays visible in *Active*. ## Several jobs at once Through the checkboxes in the list you apply *Pause*, *Resume*, *Stop*, *Run Now* and *Delete* to several jobs together. Only what applies to **every** selected job is offered. ## Following up a failed scan *Failed Scans* under *Action Required* names the modules affected within the last 24 hours and leads to *Scan › Failed*. Open the row and go through *Last Scan Details*; with many entries the search for a hostname or an error term helps. If the job already succeeded once in the *Execution History*, the cause is more likely the environment than the configuration. *Show Configuration* lays open targets, credentials, module settings and schedule. *Edit* opens the wizard with the stored values, *Run Now* starts the job immediately. ## Related Whatever a scan found but could not assign to a type appears under [Unknown Systems](/docs/en/scan/unknown-systems). Everything assigned becomes an asset from then on, which you can add [ITAM data](/docs/en/itam/manage-data) to. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.