Skip to content
Sections
All notes

All notes · Patching

Reboots, and the Conversation Nobody Wants

Patches that need a restart are not applied until the restart happens. The gap between those two is where compliance quietly fails.

Patching · Analysis

A patch installed and pending reboot is not protecting anything. This is the single largest gap between reported and actual patch state in most estates.

The control described in “Reboots, and the Conversation Nobody Wants” also consumes technician time before, during and after each maintenance window. A provider evaluating the productivity guide can record that operational effort by client and work item, making verification and follow-up visible without confusing a timesheet with proof that a patch succeeded.

For an independent operational benchmark, compare the local practice with CISA guidance on patches and updates; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

The size of the problem

Machines run for weeks between restarts, especially laptops that are only ever suspended.

Users dismiss restart prompts indefinitely.

And servers have windows that are narrow, infrequent, or theoretical.

A compliance report counting installed patches overstates protection by whatever this gap is, and most providers do not measure it.

Measuring it

Pending-reboot count across the estate, and time since last restart.

Both are available from the agent.

Report them alongside patch compliance rather than instead of it.

The first time you look at uptime across a client estate is usually instructive.

The forced reboot question

Forcing restarts applies the patches and loses unsaved work.

Not forcing them leaves machines unprotected indefinitely.

This is a client decision, not a technical one, and it should be made explicitly at onboarding rather than defaulted into by whoever configured the policy.

A workable middle

Prompt with a deadline: notify, allow deferral a stated number of times, then restart.

Outside working hours where the machine is on.

With a clear message that says what is happening and why, because an unexplained forced restart generates a ticket and a grievance.

Servers

Different problem: the window is agreed, narrow, and often monthly.

Dependencies and order matter.

And some servers genuinely cannot restart without coordination with the client's own operations, which is a scheduling conversation rather than a monitoring one.

The laptop case

The hardest. Machines that are rarely on your network, suspended rather than shut down, used by people who defer everything.

Options: a deferral deadline, a maximum uptime policy, or accepting the gap and reporting it.

Pick one deliberately, because the default is the third without anybody choosing it.

Telling the client

A report showing compliance of ninety-something per cent and a pending-reboot figure of a third tells a different story from compliance alone.

Show both.

This is uncomfortable and it is the honest number, and it is also the argument for the reboot policy you want them to agree to.

What to check

What is your pending-reboot count right now?

What is the longest uptime in your estates?

Is there an agreed reboot policy per client, or a default?

And does your compliance reporting show the pending gap?

The point

A patch installed and pending reboot protects nothing.

This is the largest gap between reported and actual patch state in most estates.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.