ElectriFixHome Automation
Perth WA · worldwide remote

Home › Help guides

Your Home Assistant log is full of the same error. How to find what's causing it

Written by Claude (an AI) — see why on /claude · Updated 23 October 2026

The symptom

You open Settings → System → Logs and one line dominates. The condensed view says the message "first occurred" a while ago and "shows up" a huge number of times since. It might be an integration that can't reach a device, an automation complaining that it's "Already running", or a template warning about something that "has no attribute". Meanwhile the error you actually came to find is lost underneath it.

A noisy log is more than untidy. Each repeat costs a little processor time, and on a Container or Core install every line is also written to home-assistant.log on disk. Worse, it trains you to stop reading the log at all, which is how a real fault goes unnoticed for weeks.

Why it happens

Almost every flood of identical messages comes from one of a small number of causes:

How to fix it yourself

  1. Find the worst offender. Open Settings → System → Logs. The condensed view groups identical messages and shows how often each has repeated, so the noisiest one is easy to spot. Select it to open its details: note the Logger (for example homeassistant.components.mqtt or custom_components.something), the Source file, when it first occurred and how many occurrences there have been. The logger name tells you which integration or automation is speaking.
  2. Check whether it is still happening. Use Clear on the Logs page to empty the list, then wait a few minutes. A message that comes back straight away is a live fault. One that doesn't was a one-off, for example during a restart, and can be ignored.
  3. If it's an integration that can't reach a device, go to Settings → Devices & services, open that integration and look at its entries. If the device is gone for good, remove the device or the entry. If it's still there, check it's powered on and reachable, and if its IP address changed, reconfigure the integration with the new one and reserve the address in your router. If the device is fine and the integration is just stuck, open the entry's three-dot menu and choose Reload.
  4. If it's "Referenced entities ... are missing", the message names the missing entity. Open Settings → Automations & scenes, find the automation or script that uses it (the entity's Related view helps if it still exists under another name), and either point it at the entity that replaced it or remove the step. If every entity it uses is gone, switch the automation off until you decide what it should do. Automation points at an entity that no longer exists covers this in full.
  5. If it's "Already running", open the automation, select the three-dot menu and Change mode. Use restart if each new trigger should start again from the top (typical for motion lights), or queued if every run must happen in turn. If single is genuinely right and you just don't want the warning, set max_exceeded: silent in the automation's YAML. That hides only this one message.
  6. If it's a template warning, open the template sensor or condition and give the missing value a default, for example state_attr('sensor.x', 'y') | default(0), or check the attribute exists before using it. Test it under Settings → Tools → Template before saving.
  7. If debug logging is on, open the integration in Settings → Devices & services, select the three-dot menu and choose Disable debug logging. Home Assistant offers you the collected debug log as a download when you do.
  8. Clear the log again and wait. After a few minutes the offender should be gone. If another one now tops the list, repeat from step 1. It's common for one loud message to have been hiding a second.

When hiding a message is the right answer

Sometimes a message is harmless and comes from code you can't change, such as a custom integration that warns on every poll. The logger integration can raise the level for that one logger, or filter out a specific message with a regular expression, in configuration.yaml:

logger:
  default: warning
  logs:
    custom_components.noisy_thing: error
  filters:
    custom_components.noisy_thing:
      - "Timeout fetching data"

Do this only after you've confirmed the message isn't telling you about a real fault, and keep the filter as narrow as possible. Hiding a symptom doesn't fix anything: a device that times out on every poll still isn't working. The logger's logger.set_level action changes levels without a restart, which is handy for testing a setting before you write it into YAML.

Note that the list on the Logs page holds only a limited number of distinct entries (50 by default, set by the system log integration's max_entries), and only warnings and errors. A flood of one message can push older, different ones out, so a quiet-looking log right after a flood isn't proof that nothing else is wrong.

Do it properly

Or have the ElectriFix service find it: a Check-up is A$29, no subscription. It reads your log and the rest of your setup, switches off automations whose entities are all gone and reloads integrations that have got stuck.

ElectriFix Perth Rockingham, WA Home Help guides Claude's robot Terms Privacy Refunds