System health
Operating it
What each check means, and what to do when one fails.
Administration > System health is the page that answers "is this working,
and how do I know?" Everything on it is read-only. It reports; things are
changed in Administration.
It never shows a credential. It shows whether one works.
The two core checks
The heading counts these, and only these.
The log store read. The portal read findings back, recently. This is the
one that matters most, because every page in the console is derived from that
read. If it fails, the console is not wrong - it is empty, which looks like a
quiet estate rather than a broken pipe. The card shows when the last
successful read was.
The tool registry. The portal loaded the catalogue of tools to detect
against, and the card shows how many are in it. Without it, collectors have
nothing to look for and the console has nothing to name.
Two of two passing means the portal can read what it needs and knows what it
is looking at. It does not mean your fleet is reporting - that is
Detection sources.
The rest of the page
Application - the version running, and the route it was deployed by
(Helm, Kubernetes or Compose). Worth checking after an upgrade.
Report signing - whether evidence snapshots and the AI inventory are
signed, and the public key to check them against. If no signing key is set
they are checksummed but not signed, which is enough to spot corruption and
not enough to prove provenance to an auditor. See Evidence.
Access and integrations - what the portal can currently do, without
naming any credential.
Enrolled devices - how many machines hold a device credential.
Updates - whether a newer version exists, and the wheel for upgrading
from your own machine. See Upgrading Nyxus.
Subscription - the state of your licence and when it was last confirmed.
Release notes - what changed, version by version.
Provided by configuration - the values this deployment was given, so you
can see what it thinks it was told.
What each failure costs you
What fails | What you see | What it means |
|---|---|---|
Log store read | Pages with nothing on them, no error | Findings may still be arriving and being stored. Nothing can read them back. |
Tool registry | The console cannot name tools; collectors report nothing | Collectors fetch the registry at runtime, and a collector that cannot parse it exits rather than reporting an empty scan. |
Report signing not set | Exports carry a checksum, no signature | Fine for your own records. Not enough for an auditor who needs provenance. |
Subscription not confirmed | A warning, from the first day | Fourteen days of grace, then no new findings and no new enrolments. |
Reading the log store card
"Reporting" means a read succeeded recently. "Failing" means the store is
configured and the read did not work. "Not set" means no store is configured
at all, which on a new deployment is the expected state until the first-run
wizard is finished.
A failing read is nearly always one of three things: the URL, the credential,
or which of the two URLs went where. The portal and the receiver use
different log-store URLs - the receiver posts to a full push endpoint, the
portal appends its own query path to a base URL - and swapping them produces a
deployment where findings are written and cannot be read.
Troubleshooting has the checks in order.
When to open support
Everything on this page is self-reported by the portal, so it is honest about
what it can see and silent about what it cannot. If the two core checks pass,
the fleet is reporting, and something still looks wrong, that is worth sending
to us: include the version from the Application card, the route, and what the
log store card says. See Releases and support.