## TL;DR
A reboot-ack timeout is usually a timing model problem: the coordinator expects the host back in a fixed short window, but hosts with many services, disk checks, or firmware updates take far longer, and the agent own probe may target a service that starts late. Replace the single timeout with staged readiness: ping, then SSH or WinRM, then the patch agent or service check, over a generous total budget, and record hosts as reboot-pending rather than failed while they are inside that budget.

```text
patch coordinator agent failed on reboot-ack timeout
```

## Use this when
- The coordinator marks hosts failed at the reboot step, but they are up and healthy when checked.
- Large database or storage hosts fail this step more than small VMs.
- The timeout value is a single flat number for every host class.

## Not for this skill when
- The host truly never returns and needs console recovery. That is a boot incident, not an ack timeout.
- The coordinator never sent the reboot because the pre-reboot command failed. Different step, different error.

## Steps
1. Measure real reboot durations per host class from logs (reboot issued to SSH answering). Verify: you have a duration distribution, not a guess
2. Replace the single ack wait with staged probes: network reachable, remote exec answering, then patch-relevant service up, each with its own sub-timeout inside one overall budget based on the measured worst case plus headroom. Verify: the staged probe logic is in the coordinator config or code
3. Change the state model so a host inside its reboot budget is reboot-pending, excluded from failure counts and from duplicate reboot commands. Verify: the wave tracker shows the pending state distinctly
4. Add a hard ceiling (for example 60 minutes) after which the host escalates to a human with console instructions. Verify: a simulated hung host escalates rather than waiting forever
5. Run the next wave and compare reboot-step failures. Verify: reboot-ack failures drop to only genuinely stuck hosts

## Variant phrasings
### reboot acknowledgement timeout patch coordinator staged readiness
The fix-pattern phrasing.
### agent gives up waiting host reboot slow host returns later
The symptom phrasing.
### reboot pending state vs failed state wave tracker
The state-model phrasing.

Compatibility: Compatibility: Coordinator agents using SSH, WinRM, or cloud APIs for reboot orchestration; timings must be tuned per fleet.

## Why it happens
Reboot time is dominated by things the patch did not change: firmware POST, filesystem checks on large volumes, and service start ordering. A coordinator written against laptop-class reboot times will systematically fail exactly the biggest, most important servers. Staged probes also fix a subtler bug: probing the patch service first makes a host look dead while it is simply still starting services.

## Edge cases / pitfalls
- Firmware updates bundled with some patches extend reboot by 10 minutes or more; detect that case from the patch metadata and extend the budget automatically.
- Never issue a second reboot to a host in reboot-pending state; a double reboot mid-service-start creates the failures you are trying to avoid.
- Record actual reboot durations per host; the fleet timing model should learn from every wave.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tHVs9tyJfnDg_0OaRgnemg