Monitoring
Scheduled discovery cycles, the diff, the alert rules and the sealed digest — what runs after the engagement.
Purpose
The engagement produces a position at a point in time. Monitoring keeps it true: a cycle re-runs the outside-in scan for the monitored domains, derives alerts from what changed, and seals a digest.
Steps
- On Console › Analyst Console, open the Monitoring schedule card.
- Cadence — Weekly — one cycle every 7 days, Daily — one cycle every 24 hours, or Off — no scheduled cycles.
- Monitored domains — the domains a cycle scans. A cadence other than off requires at least one.
- Press Save monitoring schedule. The card is explicit: Saving a cadence does not start a scan — the first cycle is one interval away. Cycles run unattended; nobody has to be signed in.
- Read results on Operations › Alerts, tabs Alert feed, Alert rules, Monitoring.
What the screen shows
Monitoring status on the console reads Not scheduled yet, Monitoring off, Next cycle: …, or Monitoring on — next cycle not stamped.
Run history on the console lists every cycle with Trigger — Analyst for a run someone started, Monitoring for a scheduled one — and a Change column holding the diff against the previous cycle.
Alerts › Monitoring is read-only; the cadence is set on the console, and the tab links back to it (Change the schedule / Set a cadence on the Analyst Console). It shows the cadence, the next cycle, the monitored domains, and Sealed cycle digests, newest first. A rehearsal cycle is badged Mock (rehearsal data).
Alerts › Alert rules lists each rule as Rule · Rule key · Condition · Severity · Channel · Status. The condition column is the measured test, so the tab cannot promise a check the engine does not perform. Turning a rule off does not delete the alerts it already raised: those keep an explicit rule off chip meaning its rule is disabled — this alert stays open but is no longer refreshed.
Quantum-vulnerable high-value certificate is off by default. Its condition needs a high-value flag on the evidence row, and nothing in the scan path writes that flag — only an import can carry it. Switching it on for an estate whose flags nobody sets would advertise a check that cannot fire. Turn it on only for a tenant that actually labels high-value evidence.
When alerts are derived
Alerts are re-derived from the estate after every completed scan cycle and after every committed certificate import. Derivation upserts on the alert key, so triage survives and re-running is idempotent. A derivation fault never turns a committed import or a completed scan into a failure — the backlog is one cycle stale and the fault is logged with the run and organisation.
Each cycle seals one monitoring_cycle event into the activity chain with the system actor system:monitor — a cycle is closed by the monitor, not a person, even when a person started the scan — plus the mode, the trigger and the counts.
Provenance
| Figure | Tier |
|---|---|
| Alerts derived from a real cycle | live |
| A rehearsal cycle's rows | stamped mock; excluded from board-facing reads |
| The sealed digest line | live — it is inside the hash chain |
| Next cycle time before the first run | empty — not stamped, not a guess |
Common failures
- A cadence was saved and nothing happened. Correct. The first cycle is one interval away; the console says so.
- Cadence saved with no domains. A cycle has nothing to scan until one is added; both screens say so.
- A host stops appearing. Not observed this cycle means the scan did not see the host — it is not evidence the host was decommissioned.
- Expecting alerts from a rehearsal estate. Mock rows are excluded from the rules, so a mock schedule raises nothing. That is deliberate; do not demonstrate alerting on mock data.
- No cycles at all, real mode. The worker process is not running the tick. Check the worker deployment before blaming the schedule.
Previous: Deliverables
All steps: Analyst method