Skip to content
Go to k12panel.com
  • There are no suggestions because the search field is empty.

What Is PC Health & Self-Healing (SOAR)?

PC Health is K12Panel's way of continuously watching the condition of your managed Windows devices — is the disk filling up, has a machine gone too long without a reboot, is a critical service stopped — and, when you want it to, fixing those problems automatically before anyone files a ticket.

This article introduces the ideas behind PC Health: what a health check is, what the industry calls SOAR, and how K12Panel applies that same pattern to keep everyday devices healthy. If you just want to turn it on and use it, see Using PC Health in K12Panel. If you want to write your own checks or fixes, see Writing Custom Health Checks and Writing Custom Remediations.

The problem PC Health solves

Most device problems are boring, repetitive, and completely predictable: a disk creeps toward full, a print spooler dies, a laptop hasn't rebooted in six weeks and updates are stuck. None of these are emergencies on day one — but left alone they turn into a help desk ticket, a frustrated teacher, or a device that quietly stops working.

Traditionally you find out about these late (when someone complains) and fix them by hand (remote in, run the same three commands you always run). PC Health flips that around: K12Panel measures the condition on a schedule, tells you when something crosses a line you care about, and — if you allow it — runs the fix for you and confirms it worked.

The building block: a health check

A health check is a small measurement taken on the device. Think of it as a sensor that answers one question with one number, for example:

  • Disk free — how many percent of the system drive is free?
  • Uptime — how many days since the last reboot?
  • Pending-reboot age — how many days has a reboot been pending?

K12Panel ships with a set of built-in checks, and you can write your own (any measurement a short PowerShell command can produce — a service's state, free memory, certificate days to expiry, last backup age, and so on).

A check only measures. What counts as "bad" is decided separately, in a policy, where you set the thresholds (called bands) — for example, "warn under 15% free, critical under 5%." That separation is deliberate: the same disk-free check can be strict for servers and relaxed for student laptops, just by binding a different policy.

When a measurement crosses a threshold, K12Panel raises a PC Health issue on that device (a warning or a critical), surfaces it on the device's Health tab, and can email your team.

What is SOAR?

SOAR stands for Security Orchestration, Automation, and Response. It's a term that comes from the security-operations world, where teams were drowning in alerts and needed a way to respond to them consistently and automatically instead of by hand every time.

Strip away the security context and SOAR describes a simple, powerful loop:

  1. Detect — something is measured and found to be out of bounds.
  2. Decide — a rule (with guardrails) decides whether and how to respond.
  3. Act — an automated action runs to fix the condition.
  4. Verify — you re-measure to confirm the problem is actually gone, and escalate to a human if it isn't.

The important ideas SOAR contributes are orchestration (a central brain coordinates the response, rather than every tool acting on its own), automation (routine responses run without a human clicking buttons), and verification (you trust the re-measurement, not the action's own claim of success).

An honest note on terminology: classic SOAR is a security discipline, usually paired with a SIEM and focused on threats. K12Panel is not a security SOAR platform. What K12Panel does is apply the same detect → decide → act → verify pattern to ordinary device health — often called self-healing or automated remediation. So when this documentation talks about "the SOAR pattern," it means that loop, applied to IT operations, not security incident response.

How K12Panel applies the pattern

K12Panel maps the SOAR loop onto four concepts:

  • Checks are the sensors (Detect). They measure conditions and, through policy bands, determine when something is a warning or a critical.
  • Policies are the brain's rules (Decide). They say which checks run on which devices, what the thresholds are, and — optionally — which fix to run for which problem.
  • Remediations are the actuators (Act). A remediation is an action that attempts to fix a condition: clean up disk space, restart a service, reboot a device.
  • Re-checking is the proof (Verify). After a remediation runs, K12Panel re-runs the check that was failing. The issue only clears when the check passes again — the remediation's own "I succeeded" is treated as provisional.

There's a neat symmetry here. A check is a sensor: it computes one number, or reports it can't. A remediation is an actuator: it performs one fix, or reports it failed. Both are short PowerShell scripts you can write, and the server orchestrates them.

Why "the check is the source of truth"

This is the single most important design choice in K12Panel's self-healing, so it's worth calling out. A remediation might run cleanly and say it worked — but that doesn't mean the problem is gone. A disk-cleanup script can delete every temp file it can find and still not free enough space to cross back over your threshold.

So K12Panel never trusts the fix's self-report as the final word. After a remediation runs, it re-measures with the original check. If the check now passes, the problem is genuinely resolved. If the check still fails, K12Panel records the attempt, tries again (within limits you set), and eventually stops and raises the alert for a human — because at that point the automation has done what it can and the problem needs judgment.

Built-in guardrails

Automation that runs commands on devices has to be careful. K12Panel builds in several safety mechanisms so self-healing stays trustworthy:

  • Suggested vs. Automatic — a remediation can be wired as Suggested (K12Panel shows a one-click Run button, a human decides) or Automatic (it runs unattended). Suggested is the default, so you can build trust before letting anything run on its own.
  • Attempt limits and cooldowns — an automatic fix retries only a set number of times, with a waiting period between attempts, then gives up and alerts.
  • Maintenance windows — disruptive fixes (like a reboot) only run during the hours you designate, so nobody loses work mid-class.
  • A fleet circuit breaker — if a remediation starts failing across many devices, K12Panel automatically halts it and alerts an administrator, so a bad script can't stampede your whole fleet.
  • Full audit trail — every attempt, automatic or manual, is logged with its result and whether the check confirmed the fix.

What you need

  • Windows devices running the K12Panel agent. PC Health currently targets Windows endpoints managed by K12Panel.
  • No separate install and no agent changes. Health checks and remediations ride the agent's normal check-in. Adding or editing a check or a fix takes effect on the next check-in — there's nothing to deploy to the device and no agent update to wait for.
  • The right role. Access follows your K12Panel role: Managers can view health and take operational actions (mute an alert, run a suggested fix); Modifiers can edit policies and wire fixes to checks; Architects can author the check and remediation definitions themselves. (See Using PC Health in K12Panel for the full breakdown.)

Frequently Asked Questions

Is PC Health a security or antivirus feature? No. PC Health is about device condition and reliability — disk space, uptime, services, reboots, and anything else you choose to measure. It borrows the SOAR pattern from security operations, but it is not a SIEM, antivirus, or threat-response tool. For Microsoft Defender threat monitoring, see the Microsoft Defender Monitoring article instead.

Does turning this on change anything on my devices? Not by itself. Checks only read conditions. Nothing acts on a device unless you create a remediation and wire it to a check — and even then, fixes default to Suggested (a human clicks Run) until you deliberately set them to Automatic.

Do I have to use the automation to get value? No. Many teams start with checks and alerts only — just knowing "these ten laptops are almost out of disk" is useful on its own. Remediations are an optional layer you add when you're ready.

How is this different from just running a script on a schedule? A scheduled script fires blindly and doesn't know whether it helped. PC Health measures first, only acts when a real threshold is crossed, verifies the fix by re-measuring, retries within limits, respects maintenance windows, and stops itself if it's failing across the fleet — all with an audit trail.

What does "self-healing" actually mean here? It means K12Panel can detect a defined problem, run a fix you've approved, confirm the fix worked by re-checking, and only involve a person if automation couldn't resolve it — closing the loop without a ticket.

Where do I go next? To set it up, read Using PC Health in K12Panel. To write your own measurements, read Writing Custom Health Checks. To write your own fixes, read Writing Custom Remediations.