## TL;DR
Preflight timeouts on slow hosts are usually the check competing with the host normal load, or a single check (like a full package query) that is expensive on that platform. Split preflight into cheap probes first (reachability, disk via a fast call), run the expensive checks with their own longer timeout, make checks asynchronous where the framework allows, and record timeout as unknown rather than failed so the host is retried once later in the wave.

```text
agent's preflight check failed with timeout on slow host
```

## Use this when
- Preflight reports timeout for hosts that are up and patch fine manually.
- The same hosts pass preflight outside business hours.
- One check in the sequence (for example enumerating updates) takes minutes on big servers.

## Not for this skill when
- The host is unreachable on the network. That is a connectivity failure, correctly excluded.
- Preflight finds a real blocker (no disk, pending broken state). That is a true negative, not a timeout to fix.

## Steps
1. Instrument preflight to log per-check durations per host. Verify: the slow check is identified by name and time, per host class
2. Reorder checks cheapest-first and fail fast on cheap negatives (unreachable, no disk). Verify: unreachable hosts exit preflight in seconds
3. Give the expensive checks their own timeout budget sized from the measured durations, separate from the probe timeout. Verify: the slow check completes within its budget on the worst host
4. Change timeout outcomes from failed to unknown with one scheduled re-check later in the wave. Verify: the wave tracker distinguishes unknown from failed and the re-check runs
5. Compare preflight results across a wave. Verify: timeout-driven exclusions drop, and any remaining ones carry per-check evidence

## Variant phrasings
### preflight check timeout slow host staged checks agent
The fix-pattern phrasing.
### update enumeration slow windows update agent preflight
The expensive-check phrasing for Windows hosts.
### timeout unknown vs failed state patch wave
The state-semantics phrasing.

Compatibility: Compatibility: Agent frameworks with per-step timeout configuration; applies to SSH and WinRM preflight alike.

## Why it happens
Preflight bundles checks with wildly different costs. A disk-space probe is milliseconds; asking the Windows Update Agent to enumerate applicable updates can take minutes on a large server, and the yum or apt equivalent is not free either. One timeout for the bundle means the slowest check on the slowest host defines reliability, and busy production hosts, exactly the ones that matter, fail preflight spuriously.

## Edge cases / pitfalls
- Do not simply raise the global timeout: a genuinely hung host then blocks a worker for the full new duration every wave.
- Caching the expensive check result for a few hours is safe for preflight purposes and removes most of the cost.
- If a host times out at the same check every wave, treat it as a host health signal, not agent noise.

## Provenance

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