Work out kernel upgrade downtime instantly with clear inputs, formula shown and shareable results.
A rolling kernel upgrade trades window length against capacity loss: larger batches finish sooner but take more of the fleet offline simultaneously. The batch size must leave enough capacity to carry production traffic, so it follows from headroom rather than from convenience — and verification time per batch is what catches a bad kernel before it reaches the whole estate.
Rolling upgrade window
batches = ceil(hosts / batch size); window = batches x (reboot time + verification); capacity offline = batch size / hosts
No larger than your redundancy allows. If the service is sized for N-1, reboot one at a time; with 30 percent headroom you can take a quarter of the fleet.
It covers many critical fixes without reboot, but not full kernel version upgrades. Plan for rolling reboots regardless, just less frequently.