How to Prevent Home Assistant Logs From Filling the System Disk

Prevent Home Assistant logs from filling the disk by identifying the exact growing file first, correcting the repeating event, and applying retention at the layer that owns that log.

On a small home server, Home Assistant Core logs, Docker logs, Supervisor or add-on logs, and the host journal can all consume the same system disk while requiring different fixes. Measure growth over a short controlled window, preserve enough evidence to identify the writer, use reversible limits, and stop nonessential writes if the remaining space is too low for a safe restart or backup.

Identify Which Log Is Consuming Space

Record total free space, then list the largest files and directories on the affected filesystem without deleting anything. Compare sizes again after five to ten minutes while Home Assistant runs normally. The file whose size changes is more useful than a static list of old large files.

Home Assistant cases show that disk exhaustion can come from different layers, including system logs rather than the Recorder database. One resolved discussion traced the growth to the systemd journal, so the first distinction is which directory keeps growing, not whether Home Assistant appears busy.

If one Core log grows, inspect its repeated component and message. If Docker JSON logs grow, inspect the container log driver. If the journal grows, inspect the emitting service. If free space is already critically low, stop the noisiest nonessential container or Home Assistant itself before further writes make recovery harder.

Fix Repeated Errors Before Reducing Visibility

Count the dominant message and match its timestamps to a device, integration, automation, add-on, or network event. A warning repeated thousands of times usually has more preventive value than dozens of unrelated one-off entries. Save a short sample with version and trigger before changing settings.

A Home Assistant Core issue documented a Tradfri error that drove a log beyond 10 GB and exhausted the system disk. That is a version-scoped example of one integration flooding a log; it supports isolating the emitter, not assuming Tradfri or rotation is always the cause.

Disable debug logging when the capture is complete, then reload or disable only the confirmed noisy integration and repeat the original trigger. If the message rate collapses, repair that integration or its dependency. If it does not, restore the setting and move to the next verified emitter rather than suppressing all warnings.

Set Retention at the Layer That Owns the Log

Set a bounded policy for the host journal, Docker log driver, reverse proxy, and other add-ons separately. A Core logger level does not cap systemd journal storage, and a Docker size option does not rotate a file written directly inside a mounted configuration directory.

Choose limits that retain enough history to cover the interval between checks while preserving space for backups, updates, database work, and recovery. The related ZimaSpace article on Home Assistant free storage explains why consuming the final margin can break work that temporarily needs additional disk space.

Document each policy in the configuration that survives recreation. Restart or recreate only the affected service, confirm the setting is active, and keep the previous value ready for rollback. Do not use a scheduled blanket deletion as a substitute for finding an abnormal writer.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verify That Growth Stays Bounded Under the Original Trigger

Reproduce the event that caused the flood, such as a device going offline, an integration retry, a backup, or a network outage. Track the same file size, message rate, free space, service health, and automation response for longer than the previous growth window.

A passing result has a stable or rotating log footprint, no loss of required diagnostics, normal history writes, and enough free space for the next backup and update. Restart the host once and repeat the trigger so the limits are proven after service recreation.

Roll back a retention change if it removes the evidence needed to diagnose a continuing fault. Escalate with the repeated message, emitting component, version, growth rate, and storage path if the log still expands after the confirmed source is isolated; stop writes again if the disk approaches exhaustion.