Home Assistant usually keeps drives awake through Recorder writes, logs, scheduled jobs, polling integrations, or another service sharing the same disk.
No active dashboard does not mean the system is idle: sensors still change state, databases commit, logs rotate, backups run, and containers touch metadata. Record exact spin-up or I/O timestamps for one quiet window, then compare them with Home Assistant and host activity. Change one candidate at a time, because disabling several writers cannot show which one reset the drive timer.
Confirm That Home Assistant Owns the Wake Event
Observe the block device, not only the Home Assistant UI. Record the process, container, path, operation type, and timestamp associated with each wake. If the disk also stores media, downloads, metrics, or system logs, another service may be responsible even when Home Assistant appears in the same time window.
A community question about HDD sleep notes that Home Assistant behavior depends on whether it records sensors, runs scheduled work, or acts only on demand. That workload-dependent drive activity supports identifying the real writer before changing Recorder.
If process-level evidence points elsewhere, exclude Home Assistant and fix the responsible service. If Home Assistant or its database path appears at each wake, continue to classify the write. A timestamp without a path or process is not enough to assign cause.
Compare Recorder Activity With Entity Changes
Match drive writes against state-change frequency and Recorder commits during the same quiet window. High-frequency power, network, weather, presence, or diagnostic entities can continue updating overnight. The signature is regular small database activity that follows entity events rather than user sessions.
A write-reduction guide recommends recording only needed entities, limiting rolling retention, and purging routinely. Its discussion of Home Assistant write cycles provides a scoped test direction, not a reason to disable all history.
If drive wakes track specific entity updates, exclude only data with no diagnostic, automation, or history value and repeat the same idle window. If activity persists with the same cadence, restore the accepted setting and continue; the first cause did not explain the wake.
Separate Logs and Scheduled Maintenance
Check log paths, verbosity, rotation, Recorder purge or repack, backups, database checkpoints, and add-on maintenance. Scheduled work often creates a burst at a repeatable clock time, while verbose logs or retries create frequent small writes. Their signatures and fixes differ.
Disabling Recorder temporarily has been suggested as a discriminator for excessive disk writes, but it is a test rather than a permanent fix. The branch described in isolating Recorder activity helps determine whether database writes are involved.
If one scheduled job matches the wake, move it to an accepted window or storage path and retest. If verbose logging matches, return affected components to normal verbosity after diagnosis. Do not suppress error logs while an integration is repeatedly failing, because that hides the cause without removing retries.
Check Polling Integrations and Shared Services
An integration can poll a device or cloud service while every user sleeps, then record the result. Another container can scan, index, or monitor the same disk. Compare Home Assistant integration activity with host-wide process writes and temporarily pause one nonessential candidate for a single controlled idle window.
Overnight disk work may also be expected maintenance rather than a fault. The ZimaSpace breakdown of repeated overnight disk activity provides the adjacent schedule-based interpretation.
If pausing one integration or service removes the matching wakes, reduce its poll rate only when supported, fix its retry loop, or place its data elsewhere. If nothing changes, restore it and continue. Avoid using longer drive standby timers to conceal continuous writes that still prevent sleep.
Retest One Full Idle Cycle
After the matched change, restart once to clear temporary diagnostic state, then reproduce the same quiet window with the same sensors, services, and drive standby policy. Record whether the disk sleeps, how long it remains asleep, and which essential events still wake it.
PASS means unnecessary wakes disappear while Recorder, automations, and recovery data still behave as required. A drive that wakes for a deliberate backup or important state change may be operating correctly. The goal is explained and bounded activity, not zero I/O at any cost.
Escalate when the device never sleeps despite no observed writes, reports hardware errors, or wakes from filesystem or kernel activity outside the application. Those results belong to storage, power-management, or controller diagnosis rather than further Home Assistant pruning.
Support & Tips
More to Read

Home Assistant Works on Wi-Fi but Fails on Ethernet or VPN
Test each network path separately, verify interface and routing state, distinguish direct IP from discovery, then repair only the failed layer.

How to Decommission Home Assistant Without Leaving Unprotected Data
Prove the replacement or archive, revoke every trust path, sanitize each data-bearing device, and retain only documented protected recovery copies.

Should You Use Automatic Updates for Home Assistant on a Home Server?
Choose manual, notification-only, or staged automatic updates from household impact, compatibility risk, observation time, and recovery readiness.

