System & Health: support reference¶
Internal. The customer-facing explanation is in the screen reference.
These are the screens that tell you whether the platform itself is working. Reach for them when a symptom spans several modules — that pattern is almost never a module fault.
Symptom-to-screen¶
| Symptom | Look at |
|---|---|
| One module's data is stale, others fine | Beats — the job that maintains it |
| Figures wrong by a consistent interval | Beats — a stopped job, which reports no error anywhere else |
| An import "did nothing" | Import, including the child processes |
| Counts moved after a scan | Health Check |
| Notifications not arriving | Email logs, then the template's trigger and frequency |
| Nothing is processing at all | Process Manager |
| Sign-in failures for some users | Active Directory logs |
Beats¶
The periodic jobs that keep derived data current — SLA states as dates pass, pre-computed statistics.
Initiated At against Processed At is the pair that matters. A job initiated and never processed is stuck. A gap growing run on run is falling behind, and everything it maintains is increasingly stale.
Figures wrong by a fixed interval rather than randomly are almost always a stopped beat. Nothing in the product raises an error for it, which is why this screen exists.
Import child processes¶
One import spawns several processes, and the parent completing does not mean every child did. An import reporting success with fewer rows than expected usually has a failed child, visible only in the child view.
Health Check, and the match key¶
Health Check reconciles what a source reported against what NxSAM holds. Everything on it depends on Match Key — the field used to decide two findings are the same one.
High New and high Fixed with near-zero Repeated is a matching problem
That combination means findings are being seen as fixed and new rather than as the same finding twice. It is a matching-configuration problem, not data loss — and it looks exactly like data loss, which is why it escalates.
Re-open distinguishes a finding that came back from one that never left. A high re-open count against one asset usually means a fix that does not survive a rebuild.
Process Manager¶
Background work runs here. Logs is where a failure explains itself.
Restart is not free
A worker restarted mid-message leaves its job in progress with nothing consuming it — the job neither completes nor retries. Prefer letting a job finish, and check what is running before restarting.
Email¶
Two screens, two questions. Templates decide what is sent and when: a template that is active with no trigger sends nothing, and one with a daily frequency sends at its time rather than when the event occurred — which is why an SLA warning can arrive "a day late".
Email logs record what was actually attempted, with recipients. Added On is when the mail was queued, not delivered; a queued message that never sent points at the mail server.
Asset limits and SLA configuration¶
Both change behaviour without any data changing:
- Reaching an asset limit mid-import produces a partial inventory.
- Changing an SLA duration re-derives expiry dates, which can make a batch of findings overdue overnight with nothing else having happened.
Queries¶
Administrative operations bound to tasks. They are tooling rather than a working screen, and running one without knowing exactly what it does is not recoverable through the interface. Do not run one to explore.
What to collect before escalating¶
- Which modules are affected — one, or several.
- The relevant Beats entry, with both timestamps.
- For imports: the parent status and every child status.
- For count movements: the Health Check row, including Match Key and Classification.
- For notifications: the email log entry, and the template's trigger and frequency.