How to Reduce Home Assistant Startup Time After Reboot
Home Assistant startup time should be reduced by finding the stage that is actually waiting, not by disabling random integrations or upgrading the server first. A reboot can expose dependencies that are already ready during an ordinary Home Assistant restart: DNS, network storage, an external database, MQTT, USB radios, or other containers may still be starting.
Measure the slowest integration, compare a Home Assistant-only restart with a full host reboot, and fix the dependency that explains the difference. A fast second restart after the machine is fully awake is strong evidence that startup ordering or an external dependency matters more than raw CPU.
Use Integration Startup Times Before Changing the Configuration
Home Assistant exposes integration startup timing so you can see which integrations delay the boot sequence. Start there instead of reading the total startup time as one number.
Home Assistant now documents this diagnostic directly: Settings → System → Repairs → Integration startup time shows which integrations are delaying startup and may have connectivity problems. Use that panel before treating total boot time as a hardware problem.
Record the same panel after a normal Home Assistant restart and after a complete server reboot. The integration whose setup time changes most is usually more useful than the one that is merely always a little slow.
Separate Core Startup From Dependencies That Are Not Ready Yet
A full reboot starts the network, storage, DNS, databases, brokers, radios, containers, and Home Assistant in overlapping windows. If Home Assistant starts before one required service is reachable, setup can spend time waiting or retrying.
Slow startup often means an integration is waiting for a device or service that is not ready yet. Home Assistant's current integration guidance explains that temporarily unavailable dependencies should enter a retry path instead of blocking normal recovery indefinitely.
Do not add arbitrary sleep delays to the whole container unless you have proved which dependency needs time. Prefer an explicit health check, stable DNS, correct mount ordering, or a service dependency that represents real readiness.
Check Recorder When Startup Pauses Around the Database
Recorder can delay startup when the database needs a schema migration, is slow to open, or is external and not yet reachable. During migrations, Home Assistant may deliberately wait rather than abandon the database in a partially migrated state.
If the UI reports Recorder as the slow component, inspect database logs, storage latency, free space, and external database reachability. Do not delete the database simply to make startup faster unless preserving history is genuinely unimportant.
Keep the diagnosis specific: a slow SQLite open is a storage problem, while an external PostgreSQL or MariaDB connection timeout is a network/service-readiness problem.
Disable or Update Custom Integrations That Block Startup
Custom integrations can add dependencies or startup behavior that Home Assistant does not test as part of the official release. If startup became slow immediately after an update, compare the timing with custom integrations disabled or updated.
Home Assistant's current troubleshooting workflow recommends restarting in Safe Mode to remove custom integrations, custom cards, and custom themes from the test. If startup improves there, the slow path is outside Home Assistant Core.
Remove one suspect at a time and repeat the same reboot test. A one-off fast boot is not enough; require the improvement to repeat.
Remove Startup Work That Does Not Need to Be Synchronous
Not every report, scan, camera task, API refresh, or custom automation needs to run immediately when Home Assistant starts. Spread non-critical work away from the first minutes after reboot when the system is also restoring integrations and state.
The ZimaSpace explanation of event-driven work versus scheduled background bursts is useful here: the goal is to protect the latency-sensitive startup path rather than eliminate all later work.
Startup is improved when the same required integrations become ready sooner and the machine reaches a stable control state faster—not merely when the login page appears a few seconds earlier.
FAQ
Why is Home Assistant slow only after a full server reboot?
That usually points to a dependency that is not ready yet, such as DNS, storage, MQTT, a database, or a radio service. Compare integration startup times after a host reboot and a Home Assistant-only restart.
Recommended products
Support & Tips
More to Read
Signs That a Home Assistant Database Needs Maintenance or Replacement
A large Home Assistant database usually needs retention or purge work; repeated corruption or integrity errors are stronger replacement signals.
How Many Concurrent Users Can Home Assistant Handle Before It Slows Down?
Home Assistant has no fixed useful user limit: benchmark active clients with real dashboards and entity updates, then stop before repeatable latency appears.
Can Home Assistant Use an External Database Without Breaking Upgrades?
An external Recorder database can survive upgrades, but adds its own availability, schema-migration, backup, restore, and version responsibilities.
