--- title: How to Use PC Health in K12Panel description: "Set up PC Health in K12Panel: policies, checks, thresholds, automated remediations, maintenance windows, muting alerts, roles, and the remediation Runs log." --- [Skip to content](https://k12panel.com/kb/pc-health-and-soar/how-to-use-pc-health-in-k12panel#main-content) ![test-full-word-logo.png\]](https://k12panel.com/hs-fs/hubfs/test-full-word-logo.png?height=35&name=test-full-word-logo.png) Open main navigation Close main navigation - [Go to k12panel.com](https://k12panel.com) [Go to k12panel.com](https://k12panel.com?hsLang=en) Hello. How can we help you? - There are no suggestions because the search field is empty. 1. [Online Help and Knowledge Base](https://k12panel.com/kb?hsLang=en) 2. [PC Health and SOAR](https://k12panel.com/kb/pc-health-and-soar?hsLang=en) # How to Use PC Health in K12Panel ## This is the hands-on guide to K12Panel's PC Health system: where everything lives, who can do what, and how to go from "nothing set up" to "devices monitored, alerts flowing, and common problems fixing themselves." For the concepts behind it, read About PC Health and Self-Healing first. To author your own checks or fixes, see Writing Custom Health Checks and Writing Custom Remediations. 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 checks, **templates** you can stamp into a concrete check (e.g. *Service running* for a named service), and your own custom checks. - **Remediations** — the catalog of fixes: built-ins, **templates** (e.g. *Restart a service*), 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. - [Getting started](https://k12panel.com/kb/getting-started?hsLang=en) - [Menu Functions](https://k12panel.com/kb/menu-functions?hsLang=en) - [Settings](https://k12panel.com/kb/settings?hsLang=en) - [3rd Party Integrations](https://k12panel.com/kb/3rd-party-integrations?hsLang=en) - [PC Health and SOAR](https://k12panel.com/kb/pc-health-and-soar?hsLang=en) - [FAQ](https://k12panel.com/kb/faq?hsLang=en) - [K12Panel Agent](https://k12panel.com/kb/k12panel-agent?hsLang=en) - [Blueprints Catalog](https://k12panel.com/kb/blueprints-catalog?hsLang=en) - [Writing your own Blueprint](https://k12panel.com/kb/writing-your-own-blueprint?hsLang=en) - [MSP Tools](https://k12panel.com/kb/msp-tools?hsLang=en) - [Developer API](https://k12panel.com/kb/developer-api?hsLang=en) # K12Panel Inc k12panel.com Help Center Copyright © 2026, K12Panel Inc