Test plans and runs

One check per plan, schedules, automatic monitoring, minimum intervals and what a run records.

Test plans

A plan runs exactly one check on its targets from its satellites. The wizard asks, in this order:

1. Check — grouped by category (reachability, ports & services, web & TLS, mail & file services, domains). Only checks of products the tenant has switched on are offered.
2. Targets — only the types the check makes sense on (dns and mail only on domains, ping and traceroute only on single hosts, nmap and the service checks also on networks and ranges). Targets, hosts and groups can be mixed.
3. Parameters of that check only, prefilled with their defaults.
4. Satellites, schedules and an optional immediate first run.

The check of a plan can be changed later. Plan health shows the last run per satellite and flags overdue satellites; the watchdog sends run.failed once per overdue period.

Expand to every address

With Check every known address of a host (default on) a host target is checked on all its IPv4 and IPv6 addresses and hostnames, not only the one entered.

Schedules

Schedules have a timezone. The satellite evaluates them itself, once a minute, from its cached copy of the plans — so they keep running when Polaris is unreachable. A one-time schedule that a satellite syncs up to an hour late still runs. Polaris deletes one-time schedules two days after they fired.

Slow run (nmap parameter stretch): hosts are scanned one after the other, evenly spaced over 90 % of the time until the next run, or until the end of the schedule’s time window. One-time schedules and Run now are not stretched.

Minimum interval per check

A schedule may fire more often than a check should run. At most every N minutes per check skips a slot when the check ran less than N minutes ago (30 seconds of tolerance). The effective value is the larger of

• the plan’s own value (prefilled from the system defaults, see interval defaults), and
• the system minimum for that check set by a super admin — no plan can go below it, and satellites enforce it too.

When nmap runs less often than a follow-up check, the follow-up reuses the ports of the last port scan (up to 7 days old).

Automatic monitoring

Polaris maintains these plans per tenant; they are marked (automatic) and cannot be edited:

Each satellite only gets the targets assigned to it. The scheduler re-checks the automatic plans every 10 minutes, so tenants and satellites created outside the UI are covered too.

Follow-up checks right after discovery

When a port scan on a websocket-connected satellite finds new services, the follow-up plans of that satellite run at once on the affected hosts (unless the plan uses manual ports only). HTTPS-only satellites pick them up at the next slot.

Runs

A run page updates live: every target and part (open ports, fingerprints, OS, UDP) appears as soon as the satellite reports it. A portal that cannot be reached loses nothing: the final upload repeats everything and Polaris skips what it already has.

Debug (parameter of every check): every command the satellite executes is stored with the run, with exit code and output (up to 64 KiB each). Checks without an external command (DNS, HTTP, SMTP, FTP, certificates) have no commands to show.

Runs and their raw results are deleted after POLARIS_RETENTION_RESULTS days (365). Hosts, services and their history stay.