Skip to content

The Activity page

Activity in the sidebar is the Hub's operational log: what it did, what its Scouts reported, and what went wrong — newest first, with a coloured dot per entry and a row of filter chips above the list.

What the colours mean

Every event has exactly one severity, and the severity comes from one table in the Hub, keyed on what the event is — not on which part of the code raised it. Read the dot, not the wording:

Dot Severity What it means Examples
Green success Something finished the way it should. Scan cycle completed - 12 endpoints scanned, External probe of x completed - score 95, Renewal completed for x, Command deliver_cert completed for x
Blue info Progress. Nothing to do. Scout acknowledged command …, Command … dispatched to Scout …, Deployment verification queued …, Management started for …, MCP client connected …
Amber warning Something did not go to plan but the Hub is still working on it, or the fact needs a look. Scan cycle completed with errors - 1 of 12 endpoints reported a scan error, Verification attempt 3 of 10 failed for x … Next check in 20 minutes, Scout x has gone dark, Failed login for "admin" from 203.0.113.9, The password for "admin" was reset from the Hub host command line, The Hub could not get renewal timing from the CA for x: … it keeps the CA's last suggested time (…) until a check succeeds
Red error An operation failed and will not fix itself. Open the endpoint (or the Scout) it names. Deployment verification gave up …, Renewal failed / rolled back / timed out for x, Command x … expired …, Command x failed for y, The Hub has been unable to get renewal timing from the CA for x for more than 24 hours (checks failing since …; the CA last answered on …) …

Three rules follow from the table:

  • A scan or probe is only green when it succeeded. A Scout that could not complete a handshake, or ran out of time partway through a cycle, raises an amber entry naming the endpoint(s) — never a green "completed".
  • Retries are amber; giving up is red. A failed verification attempt with attempts left says which attempt of how many and when the next check is. Only the final give-up, and every terminal renewal failure, is red.
  • A standing condition is announced once, not per check. The Hub's check of a CA's renewal timing (ARI) raises one amber entry when it starts failing, one red entry once it has been failing for more than 24 hours, and one blue entry when the CA answers again — never an entry per failed check. The amber and red entries carry the CA's reason and the date the CA last answered; what the Hub does meanwhile is on the endpoint's Manage drawer.

Filtering

The chips above the list are toggles — All, Errors, Warnings, Success, Info — each carrying its count over the window the page reads (the Hub's newest 200 events). Press one to show only those events, press several to combine them, press it again (or All) to clear.

The counts do not change when you filter: Errors 3 reads the same whichever chip is pressed, and a pressed chip's count is exactly the rows under it.

The filter is in the page URL — /activity?severity=error,warning is the failures view — so it can be bookmarked or linked to. That is where the header's Pipeline health card sends you when it says "N recent operations failed … Open Activity to see which operations failed and why": straight to the errors and warnings, not to the top of an unfiltered list. When failures exist, the line above the list states the mix ("2 errors, 5 warnings among the last 200 events") and offers the same link.

Expired commands: two different failures

A command the Hub sends to a Scout has a one-hour window. When it expires the entry is red and says which of two things happened:

  • "… expired: it was never delivered - Scout x was offline past the delivery window …" — the Scout never received it. Check the Scout (see Scout-went-dark alerts).
  • "… expired: it was delivered to Scout x at … but never acknowledged as completed …" — the Scout received it and the Hub never recorded a completion. The Scout's own log names every command it handled (serving declaration handled verb=… outcome=… for declarations), so the Scout side can be checked directly.

Either way the command is not retried automatically; the entry names the verb and the hostname it concerned.

  • Monitoring the estate — the daily reading order: the Manage summary, the health indicator, this page, the Scouts page.
  • When the link drops — the alerts that fire when a Scout or the Hub loses its connection.