Solved: Home Assistant "No State History Found"

Last updated: January 19, 2026

If you’ve been using Home Assistant for any length of time, you’ve almost certainly run into the dreaded message: “No state history found.” Suddenly, your sensor graphs are blank, and you’re flying blind. This frustrating error is one of the most common issues for users, but luckily, there’s a permanent fix. The problem originates in the heart of your system: the database.

By default, Home Assistant uses a SQLite database—a single file named home-assistant_v2.db—to log every state change for all your entities. With dozens or hundreds of devices, this file can grow uncontrollably until it hits a limit or becomes corrupted, triggering the error. In this definitive 2026 guide, we’ll show you how to fix and, more importantly, how to prevent this problem for good.

Understanding the Cause: The `recorder` Component

The component responsible for this mess is Home Assistant’s built-in recorder integration. Its job is to listen for system events and write them to the database. Without proper configuration, it saves *everything*, from the temperature sensor that updates every minute to the status of your media player.

The first step to optimizing your database is taming the recorder component. It’s not just about deleting old data; it’s about being selective about what information is truly important to you and what’s just taking up valuable space.

The Proactive Fix: Configure `recorder` in `configuration.yaml`

The best strategy is to prevent the database from bloating in the first place. To do this, we need to edit our main configuration file, configuration.yaml. You can access it using add-ons like Samba Share or Visual Studio Code.

Add the following block to your configuration.yaml. If you already have a recorder: section, just modify it.

# Example Recorder configuration in configuration.yaml
recorder:
  purge_keep_days: 14
  exclude:
    domains:
      - media_player
      - camera
    entities:
      - sensor.time
      - sensor.date
      - sensor.last_boot

Breaking It Down:

purge_keep_days: 14: This is the most critical line. We’re telling Home Assistant to automatically delete any state data older than 14 days. This keeps the database size consistent and predictable.
exclude: Here, we define what we *don’t* want to save. This is the most efficient strategy.
- domains: We exclude entire categories of devices. For example, media_player entities generate tons of state changes that are rarely useful to look at on a graph.
- entities: We exclude specific entities. The sensor.time changes every single minute, flooding the database with redundant data that provides no historical value.

My advice? Start with an aggressive exclusion policy. Think about which entities you actually need to see in a history graph and exclude the rest. Your system will thank you with much snappier performance.

The Reactive Fix: Create a Purge Automation

If you’d rather manage the purge manually or with a dedicated automation, you can use the recorder.purge service. This is the old-school method, but it’s still perfectly valid in 2026, especially with how easy the UI makes it.

Creating the Automation via the UI

This is the simplest and recommended way for most users in 2026.

Go to Settings > Automations & Scenes and click “Create Automation”.
Select “Create new automation”.
Trigger:
- Trigger type: Time.
- Select “At a specific time” and set it for a low-activity time, like 04:00:00.
Action:
- Action type: Call service.
- Service: Search for and select recorder.purge.
- Check the boxes for the data you want to configure: Keep days and Repack.
- Keep days: Enter the number of days of history you want to keep (e.g., 30).
- Repack: Enable this toggle. This will actually reclaim the disk space, but be aware that it can make Home Assistant unresponsive while it’s running.
Save the automation with a descriptive name, like “Daily Database Purge”.

(A screenshot of the UI automation editor showing the configured recorder.purge service would go here.)

Creating the Automation with YAML

If you’re a fan of the classic method or manage your automations in YAML files, the code is still very similar to how it was years ago. You can add this to your automations.yaml file.

- id: 'db_purge_daily_2026'
  alias: 'Daily Database Purge'
  description: 'Cleans the database every day at 4 AM'
  trigger:
    - platform: time
      at: '04:00:00'
  condition: []
  action:
    - service: recorder.purge
      data:
        keep_days: 30
        repack: true

The Pro-Level Solution: Migrating to MariaDB

For large installations or anyone chasing maximum performance and reliability, there comes a time when SQLite just doesn’t cut it. The next logical step is to migrate your database to a more powerful system like MariaDB.

MariaDB is a robust, enterprise-grade alternative to MySQL that works beautifully with Home Assistant. The advantages are significant:

Better Performance: Queries and data writes are much faster.
Lower Risk of Corruption: It’s a much more resilient system than a single database file.
Remote Management: You can host the database on another server or a NAS to free up resources on your main Home Assistant machine.

The migration process is surprisingly straightforward, thanks to the official MariaDB Add-on. If you’re interested in making the jump, I’ve put together a complete guide on how to install and configure MariaDB in Home Assistant.

FAQ: Common Questions About State History

What exactly does `repack: true` do?

When the recorder.purge service removes data, it actually just marks it as deleted; the home-assistant_v2.db file size doesn’t decrease. The repack: true option forces the database to reorganize itself and reclaim that empty space, effectively shrinking the file on your disk. It’s a resource-intensive process for your CPU and disk, which is why it’s best to run it during off-hours.

How many days of history (`keep_days`) should I keep?

There’s no single right answer; it depends on your needs.

7-15 days: Ideal for most users. This allows you to see weekly trends in your graphs without accumulating a massive amount of data.
30-90 days: Useful if you rely heavily on the Energy dashboard or want to analyze longer-term consumption data.
90+ days: If you need this much history, I strongly recommend migrating to MariaDB or exploring solutions like InfluxDB for long-term data storage, as a SQLite database this large will impact overall performance.

I deleted the `home-assistant_v2.db` file. Did I break everything?

Nope, you haven’t broken anything. This is the “nuclear option,” and it works. Home Assistant will simply recreate a fresh, empty database on the next restart. The only downside is that you lose all your history. More importantly, this doesn’t fix the root cause: if you don’t configure the recorder, the file will just grow out of control again, and you’ll be right back here in a few weeks or months.

Ultimately, fixing the “no state history found” error is a rite of passage for every serious Home Assistant user. By applying these strategies, you won’t just solve the immediate problem—you’ll build a faster, more stable system ready for whatever you throw at it in 2026 and beyond.