Patch Window Duration Calculator
Estimate a sequential patch window from fleet size and concurrency, then test phase timing and reserves against fit, slack and rollback needs.{{ summaryTitle }}
{{ summaryAnnouncement }}
| Phase | Duration | Share | Planning note | Copy |
|---|---|---|---|---|
| {{ row.label }} | {{ duration(row.minutes) }} | {{ percent(row.share, 1) }} | {{ row.note }} |
| Option | Concurrent | Batches | Duration | Window fit | Copy |
|---|---|---|---|---|---|
| {{ row.label }} | {{ row.concurrency }} | {{ row.batches }} | {{ duration(row.minutes) }} | {{ row.fitText }} |
A maintenance window is a time budget for changing systems and proving that they still work. The patch installation itself is only one part of that budget. Reboots, canary observation, retries, service validation, rollback capacity, and operational handoff can consume as much time as the patch deployment.
Fleet work is commonly divided into concurrency batches. Devices inside one batch are treated as running in parallel, while batches run one after another. Raising concurrency can shorten elapsed time, but it may also increase service risk, network demand, support load, or the size of a failed change. The useful plan is therefore the smallest safe concurrency that fits, not simply the largest number of devices that can start together.
| Phase | What belongs there | Why it changes the decision |
|---|---|---|
| Pre-check | Access, backups, snapshots, monitoring suppression | Fixed time spent before the first patch batch. |
| Canary | First-ring batches plus observation hold | Finds problems before the remaining fleet is exposed. |
| Production | Sequential install-and-reboot batches | Usually the largest variable portion of the window. |
| Closeout | Validation, rollback reserve, handoff | Protects recovery and service-owner acceptance. |
A duration estimate supports staffing, change approval, downtime notices, and rollback planning. It cannot establish that the chosen batch size is operationally safe, because dependencies, cluster quorum, rate limits, patch-manager capacity, maintenance sequencing, and real device variance sit outside simple elapsed-time arithmetic.
How to Use This Tool:
Model one repeatable patch cycle first, then add the fixed phases and reserves required by the approved change procedure.
- Enter Devices to patch, Concurrent devices, and the elapsed install and reboot time for one batch. Use measured batch time rather than multiplying a single-device time when devices run in parallel.
- Add post-patch validation and an exception allowance for slow nodes, retries, or deployment-manager lag. The percentage applies only to install-and-reboot batch work.
- Enter the Approved window. A value of zero returns duration without a fit target; a positive value enables slack, utilization, and minimum-concurrency checks.
- Open Advanced when the plan needs a start time, pre-check block, canary ring and hold, rollback reserve, or handoff buffer. Canary devices are part of the total fleet, not extra devices.
- Review the fit status and Fit options. If no concurrency fits, fixed phases already exceed the window or even a fleet-wide batch is too slow; shorten the fixed work, enlarge the window, or redesign the maintenance plan.
Interpreting Results:
Slack is approved-window minutes minus estimated duration. Zero or a positive value fits; a negative value is the projected overrun. A plan that barely fits has little protection against variation beyond the entered exception allowance.
- Minimum concurrency to fit is the first whole-device batch size, from 1 through the fleet size, whose modeled duration is no greater than the window.
- Utilization is estimated duration divided by the approved window. Exactly 100% fits with zero slack, but leaves no unallocated time.
- Estimated finish is a local wall-clock label. It does not convert time zones or resolve daylight-saving transitions.
- Rollback decision marks the start time plus the window minus the reserved rollback minutes. It is a planning cue, not an automated abort decision.
Technical Details:
The model assumes equal sequential batches. Each batch consumes the entered install time plus reboot time regardless of how many devices are inside that batch. Canary and production counts are rounded up independently, so a partly filled canary batch does not share unused capacity with the first production batch.
Formula Core:
For D total devices, C canary devices, and concurrency b, the two batch counts are:
When no canary devices are entered, the canary count is zero. With install minutes I, reboot minutes R, and exception allowance e percent, batch work and exception time are:
Fixed phases are added once. The canary hold is included only when at least one canary batch exists.
The default inputs illustrate the substitution: 96 devices at 12 concurrent produce 8 batches. At 18 install minutes plus 6 reboot minutes, batch work is 192 minutes. An 8% exception allowance adds 15.36 minutes, and 25 minutes of validation brings the total to 232.36 minutes. Against a 240-minute window, slack is 7.64 minutes.
Rule Core:
| Decision | Exact rule |
|---|---|
| Fits | Total duration ≤ approved window, with a 0.000000001-minute comparison tolerance. |
| No target | Approved window = 0; duration is estimated without fit or minimum-concurrency meaning. |
| Minimum concurrency | First integer from 1 through total devices whose total duration ≤ the window. |
| Finish label | Total minutes round upward to the next whole minute before being added to the local start. |
| Rollback label | Window minus rollback reserve rounds downward before being added to the local start. |
Returned durations and shares are rounded to six decimal places. Device, batch, and canary counts must be whole numbers; canary devices cannot exceed the fleet; and install plus reboot time must be greater than zero.
Limitations:
This is a deterministic planning model, not a scheduler or risk model. It assumes one batch finishes before the next starts and every batch takes the same entered time.
- Parallel work across independent rings, dependency ordering, cluster quorum, failed-node remediation, network saturation, and staff handoffs are not simulated.
- The exception allowance scales only batch work; it does not add uncertainty to pre-check, validation, rollback, or handoff blocks.
- Use observed pilot or prior-window timings and keep a separate operational margin when a hard stop has serious consequences.
References:
- Guide to Enterprise Patch Management Planning, NIST SP 800-40 Rev. 4, National Institute of Standards and Technology, April 2022.