Network Discovery

Discovery scans a network for monitorable hosts and turns what it finds into suggested checks — a faster start than adding checks one at a time. Find it under Organization → Discovery in the dashboard (/orgs/:org/organization/discovery).

Discovery is admin-only: starting a scan, promoting a discovered check, cancelling a scan and dismissing findings all require an organization admin (or owner). Other members can't reach the page at all — it lives under the Organization section, which is admin-only end to end.

Only one scan can run per organization at a time; starting a new one while another is still running or pending is rejected until you stop or wait for the first to finish.

Sources

Source	Scans	Requires
LAN	One or more CIDR ranges, e.g. 192.168.1.0/24	Nothing extra
Containers	One or more Docker-compatible endpoints (unix:///var/run/docker.sock or tcp://host:2375)	Nothing extra
Freebox	The devices known to a paired Freebox	A granted Freebox integration channel
Kubernetes	Workloads and their endpoints in one or more namespaces	A Kubernetes cluster connection

Freebox and Kubernetes only appear as selectable scan methods once a matching integration/connection exists.

Under an egress policy that refuses private targets (the SaaS default, or SP_EGRESS_ALLOW_PRIVATE=false on a self-hosted server), the server only offers the sources it can run safely:

Source	Self-hosted (default)	Private targets refused	SaaS
LAN	Available	Only from a private location	Only from a private location
Containers	Available	tcp:// only, through the policy	Not offered
Freebox	Available	Hosts listed from the box, not probed	Hosts listed from the box, not probed
Kubernetes	Available	Public API servers only	Public API servers only

A source that is not offered is hidden from the scan form, and starting it through the API answers 403 DISCOVERY_NOT_AVAILABLE. LAN is the exception: it stays in the form, and the scan then needs a private location (below).

LAN scan options

Besides the CIDR list, an Advanced options section exposes ports (comma separated, defaults if left empty), per-probe timeout (e.g. 1s, 500ms, default 1s), and concurrency (default 64; the form limits it to 256, though this is a UI guardrail rather than a server-enforced ceiling). A range estimated at more than 4096 addresses shows a warning that the scan may take hours to days, since large ranges are split into bounded chunks that scan progressively.

Kubernetes scan options

Pick a cluster connection and, optionally, a comma-separated list of namespaces — leave it empty to scan every namespace the connection can see.

Every scan requires confirming "I confirm I own or have permission to scan the listed network(s)" before it can start.

Running a LAN scan from a private location

A LAN scan runs on the in-process worker (the server host) by default. To scan a network the server cannot reach, or one it is not allowed to scan, pick a private location in the Run from field of the scan form. The location's agent then does the probing, inside its own network, and only the ranges its operator allowed.

• Only LAN scans can run from a location. Containers, Freebox and Kubernetes always run on the server.
• The picker lists private locations only. A location whose agent does not report discovery is disabled until its operator sets SP_AGENT_DISCOVERY_ENABLED=true on the agent.
• Where the server cannot scan the LAN itself (see the table above), Server is not offered and a location is required.
• Starting a scan from a location needs an admin membership of the organization, and is refused while impersonating a user.
• A server LAN scan and a location scan cannot run at the same time in one organization.
• Under SaaS, the addresses scanned from locations count against a daily limit (maxDiscoveryAgentAddressesPerDay, 65 536 per UTC day). Self-hosted servers have no limit.
• The scan page says Runs from @dc1, and checks promoted from it run from that location.
• If the agent refuses a chunk (range not allowed, discovery disabled), the progress card shows the failed chunks with the reason, and a discovery.chunk_refused event is recorded.

Lifecycle

A scan moves through pending → running → success or failed. While a LAN scan (the chunked kind) is running, a progress card shows completed vs. total chunks, plus running counts of groups and checks found so far, and it can be stopped — queued chunks are dropped before they start, and chunks already running are actively cancelled (the worker notices within its poll interval), not left to run to completion. For a scan run from a private location, the agent stops at its next heartbeat, 30 seconds at most.

Findings and promoting checks

Discovered hosts are grouped (by host, container, or Kubernetes workload) and each group carries source-specific hints: open ports and ICMP reachability for LAN/Freebox, image/state/health for containers, and kind, ready/desired replica counts, and reachable endpoints for Kubernetes.

Within a group you can select individual suggested checks, or select the whole group, then Promote selected to create them as real checks. A check that has already been promoted can't be selected or dismissed again. Dismiss removes a single suggested check, or an entire group, without promoting it — it will not resurface for this scan.

API

Full endpoint reference, all under /api/v1/orgs/:org/discovery/...: GET /types, GET /scans, POST /scans, GET /scans/:jobUid, and POST /scans/:jobUid/cancel. The generated API reference documents every request and response schema under the Discovery tag.