Reboot Duration Calculator

Estimate total reboot time: shutdown of services, POST, bootloader, kernel and service restart.

Inputs

Graceful Service Shutdown Time (s)

POST / Firmware Time (s)

Bootloader Time (s)

Kernel Boot Time (s)

Service Startup Time (s)

Total Reboot Duration

Estimated Service Outage Window

Shutdown Phase Share (%)

25.0%

Hardware (POST + Bootloader) Share (%)

38.3%

OS Boot (Kernel + Services) Share (%)

36.7%

Step by step

Values used
Graceful Service Shutdown Time (s) = 15; POST / Firmware Time (s) = 20; Bootloader Time (s) = 3; Kernel Boot Time (s) = 4; Service Startup Time (s) = 18
Total reboot time
reboot = shutdown_services + POST + bootloader + kernel + services_startup
Total Reboot Duration
= 1m
Estimated Service Outage Window
= 1m
Shutdown Phase Share (%)
= 25.0
Hardware (POST + Bootloader) Share (%)
= 38.3
OS Boot (Kernel + Services) Share (%)
= 36.7

How it works

A full reboot's user-visible downtime spans five phases: gracefully stopping running services (systemd waits up to a per-unit timeout for each to shut down cleanly), the hardware POST/firmware self-test, the bootloader locating and loading the kernel, kernel initialization, and finally services starting back up before the system is truly ready to serve traffic. On physical servers, POST time (RAID controller init, remote management handshake, memory testing) frequently dominates the total far more than the actual OS boot phases, which is an important distinction from the boot-time breakdown that starts only once firmware has already handed off to the bootloader.

Formula

Total reboot time

reboot = shutdown_services + POST + bootloader + kernel + services_startup

d: shutdown services
p: POST/firmware
l: bootloader
k: kernel
s: services startup

Frequently Asked Questions

Why does a graceful shutdown sometimes take much longer than expected?

systemd gives each service up to its configured TimeoutStopSec (90 seconds by default) to shut down cleanly before force-killing it â€” a single slow-to-stop service (e.g. a database performing a checkpoint/flush, or a service with a hung connection) can add its full timeout to total shutdown time.

Does a reboot always cause the same downtime as a full power cycle?

No â€” a warm reboot (`reboot` command) typically skips lengthy hardware self-tests that a full cold power cycle triggers (especially memory testing on server-grade firmware), so reboot time is often meaningfully shorter than a power-off/power-on cycle on the same hardware.

How can virtualization reduce reboot-related downtime?

Live migration (vMotion, virsh migrate) can move a running VM to another host entirely without a reboot for host-level maintenance, and even for guest OS patching, a VM's virtual firmware/BIOS phase is far faster than physical POST since there's no real hardware to initialize.

You might also need

Boot Time Calculator Patch Window Calculator Update Time Estimator