> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nyumbazetu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Platform health

> Run health scans, triage the issues queue, and resolve or waive findings.

**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.

<Steps>
  <Step title="Run a full scan after any large change">
    A migration, a bulk import, a configuration overhaul.
  </Step>

  <Step title="Run a targeted scan when investigating">
    Restrict to the rule codes relevant to what you are chasing.
  </Step>

  <Step title="Compare against the last scan">
    New findings since the last run are what you act on; a stable backlog is a different
    conversation.
  </Step>
</Steps>

## 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

<Steps>
  <Step title="Read the impact, not just the problem">
    Severity sorts the queue; impact decides whether it matters to you this week.
  </Step>

  <Step title="Fix the underlying record">
    Health findings point at real data. Fixing the record is the resolution; the finding closing is
    the consequence.
  </Step>

  <Step title="Record the resolution">
    Choose the resolution type and add notes. Some resolutions require a reason.
  </Step>

  <Step title="Re-scan to confirm">
    A finding that reappears was not actually fixed.
  </Step>
</Steps>

### 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.                                    |

<Warning>
  Waiving is not resolving. A waived finding stops being reported; it does not stop being true. Waive
  only where the rule genuinely does not apply, and always record why — the next administrator will
  need to know.
</Warning>

## 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

<Steps>
  <Step title="Weekly: clear new critical and high findings">
    They are usually few and usually fast.
  </Step>

  <Step title="Monthly: review snoozed findings">
    Snoozes expire; findings that were snoozed twice should be fixed or waived.
  </Step>

  <Step title="Before month end: scan and clear">
    Health findings frequently explain reconciliation differences before you go looking for them.
  </Step>

  <Step title="Quarterly: review waivers">
    A waiver that has outlived its reason is a hidden problem.
  </Step>
</Steps>

## Related

<Columns cols={2}>
  <Card title="Activity log" icon="clock-rotate-left" href="/guides/activity-log">
    Who changed what, once health tells you something changed.
  </Card>

  <Card title="Scheduled tasks" icon="clock" href="/guides/scheduled-tasks">
    Whether the jobs behind the data are running.
  </Card>
</Columns>