How to Use PC Health in K12Panel

PC Health targets Windows devices running the K12Panel agent. Everything rides the agent's normal check-in, so there is nothing to install on devices and no agent update to wait for — changes take effect on the next check-in.

Where it lives

Open PC Health from the left menu. You'll find four tabs:

Policies — which checks run on which devices, and the thresholds that raise an alert.
Checks — the catalog of measurements (built-in and your own custom checks).
Remediations — the catalog of fixes (built-in and your own), plus any that have been halted by the safety breaker.
Runs — a fleet-wide log of every remediation attempt and how it turned out.

Each individual device also has a Health tab (open a device from Assets) showing its live status, open issues, and remediation history.

Who can do what (roles)

Access follows your K12Panel role. Each role includes everything below it.

Manager — view health everywhere (device Health tabs, the Policies/Checks/ Remediations/Runs pages read-only), mute an issue, and run a suggested remediation on a device.
Modifier — everything a Manager can do, plus create, edit, and delete policies, including wiring checks and remediations onto them.
Architect — everything a Modifier can do, plus create, edit, and delete the check and remediation definitions themselves, and re-enable a halted remediation.

If you can open a page but the New / Edit / Delete buttons are missing (or a form is read-only), your role can view that area but not change it.

The device Health tab

Open any monitored device and click Health. You'll see:

The policy in force for that device.
Gauges and stoplights for each check that's set to display, with its current value and status (Healthy / Warning / Critical / Unknown).
Open issues — each current warning or critical, with the value that tripped it.
Remediation history — every fix that has run on this device, with its result and whether the check confirmed it.

From here a Manager can Mute an issue or, when a remediation is wired to it, click Run to fix it on demand.

Step 1 — Set up a policy

A policy decides which checks run on which devices and what the thresholds are. There are two ways a policy reaches a device:

Global default — one policy per organization can be the global default. It applies to every device that isn't covered by a more specific policy. This is the easiest way to monitor your whole fleet with one set of thresholds.
Group-bound — bind a policy to one or more asset groups. When a device matches, the bound policy wins over the global default. If a device matches several group policies, the one with the highest priority number wins.

To create one, go to Policies → New Policy, give it a name and a priority, and either mark it the global default or bind it to asset groups.

You can also pause a policy until a chosen date (handy for summer break) — it stops raising alerts and auto-resumes on its own.

Step 2 — Enable checks and set thresholds

Inside the policy editor, each available check has a row. For every check you want the policy to run:

Tick Enabled.
Set the Bands — the ordered thresholds that decide warning vs. critical. Bands are written as JSON rules, for example [{"op":"<","value":15,"severity":"warning"}]. The defaults are usually fine; override them only when a group needs stricter or looser limits.
Optionally adjust Debounce — how many consecutive out-of-bounds samples are required before an issue is raised (this smooths over one-off blips).

See Writing Custom Health Checks for a full explanation of bands, severities, and hysteresis.

Step 3 — (Optional) Wire a remediation to a check

This is where self-healing gets turned on, and it's done per check, inside the policy editor. On a check's row, in the Auto-remediation column, choose:

Remediation — which fix to run (a built-in like Disk Cleanup, or one you've authored). Leave it as none to alert only.
Mode — Suggested (K12Panel shows a Run button on the device; a human decides) or Automatic (it runs unattended). Suggested is the safe default — use it to build trust before switching to Automatic.
On — the severity that triggers it (Warning, Critical, or either).
Tries and Cooldown — how many times an automatic fix may retry, and how long to wait between attempts before giving up and alerting.

When a matching breach occurs, K12Panel dispatches the fix, suppresses the alert while the fix is actively running, then re-runs the check to verify. If the check passes, the issue resolves quietly. If it still fails after the allowed tries, the issue becomes a visible alert for a human.

Step 4 — Set a maintenance window (for disruptive fixes)

Some fixes are disruptive — a reboot, or restarting the agent. A remediation flagged disruptive will only run automatically inside the policy's maintenance window. Set the window's start and end times in the policy editor. Leave it blank and disruptive fixes never run automatically (they can still be run by hand). Non-disruptive fixes, like clearing temp files, ignore the window.

Muting an issue

Sometimes an alert is known, expected, or being handled another way, and you want it to stop badging. On the device's Health tab, use Mute on the issue and pick a duration:

7 days or 30 days — a temporary snooze that lifts on its own.
Indefinitely — stays silenced until someone explicitly Unmutes it.

A muted issue drops off the device's health badge and count, and it will not auto-remediate (muting means "hands off, I've got this"). The issue row shows who muted it and until when. Use Unmute to bring it back at any time.

Reading the Runs log

The Runs tab under PC Health is your fleet-wide record of remediation activity. Each row shows when it ran, the device, the remediation, the check it was fixing, the mode (Automatic or Manual), and two outcome columns:

Result — the fix's own provisional outcome (Success / Failure).
Verified — the authoritative verdict from re-running the check (Healed / Still failing).

The distinction matters: a row reading Success / Still failing means the fix ran cleanly but didn't actually resolve the condition (for example, cleanup couldn't free enough disk). That's the system correctly refusing to call a problem solved until the check agrees.

Alerts and notifications

When an issue escalates to a visible alert, K12Panel raises a PC Health Alert for the device and can email subscribed administrators. Manage who gets emailed under Profile → Notifications. Muted and actively-remediating issues don't alert.

If the safety breaker halts a remediation across your fleet, K12Panel raises a separate Remediation halted alert so an administrator knows to investigate.

Halted remediations and the circuit breaker

If an automatic remediation starts failing across many devices, K12Panel halts it automatically to prevent a bad fix from running fleet-wide. Halted remediations appear at the top of the Remediations tab. After investigating (usually by editing the remediation's script and testing it on one device), an Architect can Re-enable it.

Sharing configuration

Checks travel with the policy they're bound to. You can Export a policy or a remediation to a JSON file and Import it into another organization — useful for standardizing across schools you manage. Imported items land inactive/pending review so nothing runs until someone deliberately turns it on.

Frequently Asked Questions

I enabled a policy but a device still shows "Not monitored" or no data. Give it a check-in cycle. Health measurements ride the agent's normal poll, so a device reports its first values on its next check-in after the policy applies. If it persists, confirm the device matches the policy (group binding or global default) and that the checks you expect are enabled.

Why does a device show a Warning check but no alert on the badge? Because the issue is either muted or actively remediating. Both suppress the badge. A muted issue shows a "muted by … " marker; a remediating one shows "… running / verifying." Once a remediation gives up (or you unmute), it returns to the badge.

What's the difference between Suggested and Automatic remediation? Suggested shows a Run button and waits for a person. Automatic runs on its own when the breach occurs (subject to attempt limits, cooldowns, maintenance windows, and the circuit breaker). Start with Suggested and promote to Automatic once you trust a fix.

A remediation ran and shows "Success" but the problem is still there. That's the Verified column doing its job. "Success" is the fix's own report; K12Panel re-runs the check to decide the truth. "Success / Still failing" means the fix executed but didn't resolve the condition — so K12Panel keeps the issue open (and, if attempts remain, tries again).

Can I stop a fix from rebooting devices during class? Yes. Reboots are disruptive and only run automatically inside the policy's maintenance window. Set that window to after hours (or leave it blank to prevent automatic reboots entirely). You can still trigger a reboot fix by hand.

Who gets alerted, and can I reduce the noise? Administrators subscribed to PC Health alerts are emailed when an issue escalates. Muting an issue (7/30 days or indefinitely) silences it, and you can manage your subscriptions under Profile → Notifications.

Do I need to update the agent to add a new check or fix? No. Checks and remediations are delivered with the agent's normal check-in. Create or edit one and it takes effect on the next check-in — no device install, no agent update.