Docs
Approved, Offered, Installed, Rebooted: Windows Update States MSPs Keep Mixing Up
Learn the difference between approved, offered, installed, and rebooted Windows update states so patch reports stop collapsing different workflow stages into one misleading status.
Informational for MSPs and IT admins who need a cleaner vocabulary for Windows update workflow states
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: approved, offered, installed, and rebooted are different Windows update states, not synonyms.
When a report treats them as the same thing, the patch story becomes misleading.
Windows patching workflows usually move through several states: approved, offered, installed, and rebooted. Those states are related, but they are not interchangeable, and patch reports become misleading when they collapse them into one label.
This page gives teams a cleaner model so they can stop arguing over whether the patch "worked" when they are really describing different stages of the same workflow.
Use Microsoft's troubleshooting model when you need a primary-source frame for separating Windows update workflow stages and failure points. Microsoft Learn: Troubleshoot Windows Update issues
What You'll Get
- Separate approval, applicability, install, and reboot completion in plain language
- Reduce status-label confusion in customer reports and internal triage
- Build cleaner links between reporting pages and endpoint verification pages
The Four States
| State | What it means | What it does not prove |
|---|---|---|
| Approved | The update is allowed or targeted for deployment | It does not prove the endpoint saw or installed it. |
| Offered | The device sees the update as applicable | It does not prove the install succeeded. |
| Installed | The package was applied on the endpoint | It does not prove reboot completion or current compliance. |
| Rebooted | The endpoint completed the restart needed for finalization | It still does not replace verification against the current baseline. |
Why Mixing the States Creates Bad Reporting
Many dashboards use one simplified patch label even though the endpoint is still moving through several stages. That is why a tool can show a device as healthy when it is only approved, offered, or partially complete. A better endpoint patch status dashboard keeps those stages visible instead of hiding them behind one score or color.
The Better Mental Model
The clean sequence is:
- Approved: the workflow allows it.
- Offered: the device sees it.
- Installed: the endpoint applies it.
- Rebooted: restart-dependent work clears.
- Verified: the endpoint evidence and the current baseline agree.
Where to Go Next
If the problem is that install success still is not counted as compliance, continue to installed vs compliant Windows updates. If the problem is scan lag or old state, continue to patch scan freshness and reporting delay or real-time patch visibility. If the problem is reboot completion, continue to why updates require a restart.