Docs
Report Failed Patches: Stop Chasing Compliance Scores and Surface Real Failures
Learn how MSPs should report failed patches by tracking real Windows failure signals like Event ID 20, pending reboot state, repeated failures, and update-service health.
Troubleshooting for Small MSP teams that need a clear report of failed patches and broken endpoints
Free Audit
Run The Free Audit
If you need to separate stale scans, reboot debt, failure signals, and real patch risk across endpoints, run the free RMM Patch Health Audit.
Short Answer
Direct answer: a failed patch report should start with real failure evidence such as install failures, repeated retries, reboot blockers, and unhealthy update services.
Compliance scores can support the story, but they should not be the main proof that a patch truly failed.
If you want to report failed patches, stop starting with compliance scores. Compliance tells you how a platform summarizes patch state. It does not reliably tell you which devices truly failed, why they failed, or whether the issue is just reporting noise.
MSPs need something more practical: a list of devices with real failure evidence. That means install failures, repeated retry patterns, pending reboot states that never clear, stale update paths, and Windows Update service problems.
This page builds on the broader patch report not accurate guide, but the emphasis here is different. The goal is not to explain why the score looks wrong. The goal is to surface which endpoints are actually failing patching.
Caution: do not label every low-compliance endpoint as a failed patch. A failure report should stay grounded in evidence that explains what broke and what action comes next.
Use this guide when the real requirement is to report failed patches clearly, not to review another compliance dashboard.
Use Microsoft's troubleshooting guidance as the baseline source when deciding whether a patch truly failed or the issue is just reporting noise. Microsoft Learn: Windows Update issues troubleshooting
What You'll Get
- Build a failed patch report around direct evidence like install failures, reboot blockers, and repeated failure patterns
- Separate real patch failures from compliance-score noise
- Give small MSP teams a report that leads directly to remediation work
What Actually Counts as a Failed Patch
A failed patch is not the same thing as a low compliance score. In operations, a patch should be treated as failed when the endpoint shows one of these real conditions:
- Failed install: Windows Update attempted installation and logged an install failure, often visible in the WindowsUpdateClient operational log with Event ID 20.
- Stuck update: the same update never reaches a clean installed state and remains in a repeating offered or pending pattern.
- Repeated retry: the same update keeps attempting and failing across cycles.
- Blocked by reboot: installation activity happened, but pending reboot state never clears and the device cannot progress cleanly.
That definition matters because it separates true patch failure from false compliance noise. A score can move for harmless reasons. Event ID 20, repeated failure history, or a reboot-required loop are not harmless reasons.
Why Your RMM Does Not Show This Clearly
Most RMMs are optimized to summarize patch posture at scale, not to explain failure root cause. They normalize Windows Update Agent data into their own status model, compliance logic, and dashboard labels. That helps with readability, but it usually compresses the evidence that matters most when patching breaks.
This is why MSPs keep running into the same problem: the dashboard says devices are non-compliant, but it does not tell you whether the real issue is install failure, reboot debt, stale scan state, or just changing applicability. The abstraction hides the difference between patch failure and patch reporting confusion.
That is the same frustration behind RMM patch report wrong and patching working but shows not compliant. The status label is simpler than the Windows reality underneath it.
How to Actually Find Failed Patches
If the goal is failed patch visibility, start with the signals Windows exposes directly:
- Windows Update event logs: Event ID 20 is one of the clearest signals that an install actually failed. Event IDs for scan and download failures help separate the layer that broke.
- Pending reboot registry flags: check the common reboot-required paths under Component Based Servicing and Windows Update Auto Update to find devices that are blocked from finishing cleanly.
- Update history: compare whether installs are succeeding or repeatedly failing across the last several cycles.
- Windows Update service health: validate `wuauserv`, `BITS`, and related services are healthy enough for scan and download to work.
- Windows Update logs: use them when the RMM summary is too vague and you need to see the device's actual update behavior.
The point is not to drown a small MSP in raw telemetry. The point is to build a short evidence chain for each affected device: did it fail to scan, fail to download, fail to install, or fail to complete because reboot never happened?
What to Check Instead of Compliance Score
| Signal | Why it matters | What it usually means |
|---|---|---|
| Event ID 20 install failures | Direct failure evidence | The patch attempt actually failed on the device. |
| Pending reboot registry flags | Completion is blocked | Patching may have started but cannot reach a clean final state. |
| Repeated failed installs | Recurring issue, not one-off noise | The endpoint needs remediation, not just another patch run. |
| Service issues with `wuauserv` or `BITS` | Scan and download path is unhealthy | The problem may start before install even begins. |
| Update history mismatches | Status and activity disagree | The endpoint may be stuck between states or the reporting layer may be vague. |
This is the mindset shift: stop chasing percentages and start classifying failure evidence.
A Simple Reporting Workflow for Small MSPs
For a 1 to 10 tech MSP, the reporting workflow does not need to be fancy. It needs to answer four questions:
- Which devices have direct install-failure evidence?
- Which devices are only blocked by pending reboot?
- Which devices are stuck in repeated retry or repeated success loops?
- Which devices merely look bad in the RMM but have no strong failure signal?
If you can sort devices into those four groups, patch operations become much calmer. The tech queue focuses on real failures. The client conversation focuses on real exceptions. And the team stops mistaking score noise for broken patching.
When Patching Is Actually Broken
Patching is actually broken when devices show repeated install failures, persistent scan/download failures, or reboot-blocked states that never clear. It is also broken when the update services are unhealthy enough that the endpoint cannot even reach the install phase.
That is different from a compliance dip after new updates are released. It is different from a stale report. It is different from a device that installed successfully but has not refreshed state yet.
If you need more device-level detail, move next to Windows Update event IDs, Windows Update fails to install, and devices with failed updates.
Why This Page Beats Forum Answers
Forum answers often say to force a scan, reboot, or rerun the patch. That can help, but it does not solve the core problem: MSPs need failure visibility, not generic advice. They need to know which devices truly failed and what pattern those failures follow.
That is where PatchReporter fits. The value is not another compliance dashboard. The value is a reporting layer that surfaces real failure signals, makes failed patch visibility easier to review, and helps teams prove what is actually broken versus what is just noise.