Super Admin → Platform Health → /health
Platform Health scans your data against a rule set and reports what it finds: leases billing nothing, units with no owner, payments unallocated for too long, configuration that will fail the next time a job runs. It catches the class of problem that never throws an error — it just produces quietly wrong numbers.
The pages
| Page | Route | Purpose |
|---|---|---|
| Overview | /health/overview | Health score, open issues, critical issues, last scan, incidents over time. |
| Issues | /health/findings | The issues queue. |
| Issue | /health/finding/:id | One finding in detail. |
| Rules | /health/rules | The rule catalogue, and each rule's findings. |
| Scan history | /health/scans | Every scan run and its outcome. |
Running a scan
Run Health Scan starts a scan, with options including a full scan and severity selection (for example errors only, or specific rule codes). Progress is reported as the scan runs, and the result appears as a run snapshot with a scan timeline and outcomes.
Run a full scan after any large change
A migration, a bulk import, a configuration overhaul.
Run a targeted scan when investigating
Restrict to the rule codes relevant to what you are chasing.
Compare against the last scan
New findings since the last run are what you act on; a stable backlog is a different conversation.
The issues queue
Each finding carries:
| Element | Meaning |
|---|---|
| Rule / rule code | Which check produced it. |
| Severity | How serious it is — critical, high, and below. |
| Problem | What is wrong. |
| Impact | What it affects if left. |
| Affected record / entity | The specific record, with entity type and ID. |
| How this was detected | The evidence behind the finding. |
| Recommended action | What to do about it. |
| Suggested next step | The immediate move. |
| Detected by / last seen | Which scan found it and when it was last confirmed. |
| Status | Open, resolved, snoozed, waived. |
Quick filters, sorting and optional columns work as elsewhere; findings can be exported.
Resolving a finding
Read the impact, not just the problem
Severity sorts the queue; impact decides whether it matters to you this week.
Fix the underlying record
Health findings point at real data. Fixing the record is the resolution; the finding closing is the consequence.
Record the resolution
Choose the resolution type and add notes. Some resolutions require a reason.
Re-scan to confirm
A finding that reappears was not actually fixed.
Snooze and waive
| Action | Use it when |
|---|---|
| Snooze until | The finding is real but cannot be fixed yet — a supplier is due to confirm something next week. |
| Waiver (reason required) | The finding does not apply to your situation and never will. |
Rules
The rules page lists every check with its code and enabled severity, and lets you drill into the findings a rule has produced. Rule execution failures are shown separately — a rule that could not run is not the same as a rule that found nothing, and treating them the same is how a blind spot forms.
Health score
The overview shows a health score and incidents over time. Use the trend, not the absolute number: a score that is falling week on week is a signal even when the absolute value looks acceptable.
Working health into a routine
Weekly: clear new critical and high findings
They are usually few and usually fast.
Monthly: review snoozed findings
Snoozes expire; findings that were snoozed twice should be fixed or waived.
Before month end: scan and clear
Health findings frequently explain reconciliation differences before you go looking for them.
Quarterly: review waivers
A waiver that has outlived its reason is a hidden problem.