# Cloudflare cuts core server recovery from four hours to three minutes > UEFI and iPXE automation changes removed repeated network-interface probes and made firmware configuration survive upgrades without manual BIOS work. Canonical URL: https://www.devobs.io/news/news-cloudflare-core-server-boot-automation/ By: Samira Haddad Published: 2026-09-06T11:58:54.640Z Updated: 2026-09-06T11:58:54.640Z Event date: 2026-06-01 Section: Infrastructure Cloudflare reported on June 1 that it reduced an affected core server’s firmware-upgrade and boot process from nearly four hours to three minutes. The [engineering account](https://blog.cloudflare.com/optimizing-core-unit-boot-time/) focuses on bare-metal machines in Cloudflare’s centralized core, which runs control-plane, billing, and analytics services rather than edge request traffic. ## Repeated interface probes multiplied the delay Some nodes needed several firmware updates, each followed by a reboot. During the pre-boot PXE stage, firmware performed a linear search across network interfaces, spending about 20 minutes on each unsuccessful probe cycle. Cloudflare changed its automation to declare the correct network boot interface early for each hardware and use case, cutting roughly an hour from the multi-update sequence. Two complications remained: older UEFI versions lacked the same boot-order support, and firmware upgrades could reset configuration. Cloudflare added post-change validation that reapplies settings and reboots when necessary. It also extended an internal UEFI configuration tool to handle a vendor setting that was loaded only through a firmware UI callback. Subsequent single boots fell from about 20 minutes to under a minute. ## Boot time belongs in fleet capacity planning A server that takes hours to rejoin the fleet changes the risk of routine maintenance. Operators should measure a complete multi-update sequence on every supported hardware class, including the slow paths that a normal reboot may not exercise. Automation should verify the setting it changed rather than assume a successful command persisted across the next firmware step. It also needs bounded retries and a visible terminal state when a vendor-specific path cannot be configured. Cloudflare’s result came from controlling the early boot sequence and validating state after mutation. The broader lesson is to treat firmware as an automated, observable deployment system, not an opaque prelude to the operating system. ## Source references -