Scanning
Scanning in Lumen Edge separates what to check from when to check it:
- A scan template defines the checks and their configuration.
- A scan schedule binds a template to a target set and a cadence.
- Scan history records every run and its results.
Keeping these separate means one template can be reused by many schedules with different targets and windows.
Scan templates
Create templates under Scan templates. A template captures the check selection and any tuning that should travel with it.
Resist creating a template per team. Templates describe a class of check ("External web exposure", "Windows patch posture"); the targeting belongs in the schedule.
Enumerate the check families available in a template and the tuning options for each.
Scan schedules
A schedule answers three questions:
| Question | Field |
|---|---|
| What runs? | The scan template |
| Against what? | A target set — an asset filter, an explicit list, or a network range |
| When? | Cadence and window |
Because targets can be expressed as an asset filter, a schedule can be self-maintaining: "every Linux host in the production environment" picks up new hosts automatically as they are discovered.
A schedule whose scope grows over time can outgrow its window. If runs start overlapping or being truncated, either narrow the filter or widen the window.
The lifecycle of a task
Every run is a task: one unit of work, queued by the console and executed by the sensor the integration names. Understanding which stages happen where is what makes troubleshooting quick.
| Stage | Runs on | What happens |
|---|---|---|
| Queued | Console | The schedule has fired and the task is waiting to be collected |
| Running | Sensor | Fetching from the source, or scanning |
| Uploading | Sensor | The compressed result is posted back |
| Verification | Console | The archive is unpacked and split into one raw finding per record |
| Cleaning | Console | Housekeeping between stages |
| Identification | Console | Each record is normalised and matched against existing assets |
| Validation | Console | Change entries are checked against the integration's action settings |
| Sync | Console | Approved changes are written to the inventory |
| Finished | Console | The run is complete |
Alongside the stage, each task carries a status — pending, running, completed, conflict, verification, or error.
The same stages apply to every task, whether it is a network scan or a scheduled integration sync: only the running stage differs between probing a subnet and reading someone else's API.
A task stuck at running is a sensor-side problem: no reach, bad credentials, a scan larger than its window. A task that fails after uploading is a console-side one and the sensor is fine. The stage tells you which half to look at, and Scan history shows it per run.
When a sensor restarts it finds any task it had marked as running and puts it back to queued, so a restart mid-run costs you the run, not the schedule.
Scan history
Scan history lists every run with its status, duration, target count and the findings produced. Open a run to see per-target results and any errors.
Use it to answer:
- Did last night's scan actually complete?
- Which targets were unreachable?
- What changed since the previous run?
Findings
Findings produced by a run attach to the assets they concern, so they are visible both from the run and from the asset detail view. That two-way visibility is deliberate — you can work by campaign ("everything this scan found") or by asset ("everything wrong with this host").
See also
- Assets — where findings surface per host
- Reports — exporting findings
- Active scanner — the integration that executes network probes
- Sensors — the component that runs every scan