Rolling Update Duration Calculator
Calculate how long a Kubernetes rolling deployment will take given maxUnavailable, maxSurge and pod startup time.
Inputs
Total replica count of the Deployment being updated.
Maximum extra pods that can be created above desired replica count (maxSurge).
Time for a new pod to become Ready, including image pull, init containers and readiness checks.
Total Rollout Duration
150seconds
Total Rollout Duration
2.50minutes
Number of Waves
5
Pods Replaced per Wave
4pods
Step by step
Pods replaced per wave: maxUnavailable + maxSurge
2 + 2
= 4 pods
Waves: ceil(total ÷ per-wave)
ceil(20 ÷ 4)
= 5 waves
Total duration: waves × startup time
5 × 30s
= 150s
How it works
A rolling update replaces pods in waves bounded by maxUnavailable and maxSurge: each wave can bring up to maxSurge new pods while taking down up to maxUnavailable old ones. Formula: waves = ceil(total_pods ÷ (maxUnavailable + maxSurge)), duration = waves × pod_startup_time. Increasing either maxSurge or maxUnavailable reduces the number of waves and therefore total rollout time, at the cost of more simultaneous capacity change.
Formula
duration = ceil(totalPods / (maxUnavailable + maxSurge)) × podStartupTime
- N
- Total pods in the deployment
- U
- maxUnavailable pods
- S
- maxSurge pods
- t_s
- Pod startup time in seconds
- T
- Total rollout duration in seconds
Frequently Asked Questions
Should I increase maxSurge or maxUnavailable to speed up rollouts?
Increasing maxSurge adds extra capacity during rollout without reducing available replicas — generally safer for latency-sensitive services. Increasing maxUnavailable speeds things up but temporarily reduces serving capacity, which is riskier under load.
Does this account for readiness probe delays?
Yes, as long as your pod startup time input includes the full time to pass readiness checks — that's the point at which Kubernetes considers a pod available and proceeds to the next wave.
Why did my actual rollout take longer than this estimate?
PodDisruptionBudgets, node capacity constraints forcing pod pending states, or slow image pulls on cold nodes can all extend rollout time beyond the pure wave-based calculation.
What if maxUnavailable and maxSurge are both 0?
The rollout can't make progress — Kubernetes requires at least one of maxUnavailable or maxSurge to be greater than zero for a RollingUpdate strategy.
You might also need
- Cluster Upgrade Time CalculatorCommonly used together
- Job Completion Time CalculatorCommonly used together
- StatefulSet Capacity CalculatorCommonly used together
- HPA Target CalculatorCommonly used together
- Canary Deployment CalculatorCommonly used together
- Pipeline Runtime CalculatorCommonly used together