HAGHS - What is your Global Health Score? 🛡️

denzo · January 23, 2026, 2:46pm

Hey everyone,

How do you actually know if your Home Assistant instance is healthy?

Most of us look at raw CPU or RAM percentages, but those don’t tell the whole story. A system can have 10% CPU usage but be filled with 50 “Zombie” entities and have no backups—making it a ticking time bomb.

I wanted a “North Star” metric, so I developed the HAGHS (Home Assistant Global Health Score).

What is HAGHS?

HAGHS is a standardized 0-100 index. It’s like a “Credit Score” for your smart home. It balances your hardware performance (40%) with your software maintenance hygiene (60%).

Why you should use it:

The Advisor: It doesn’t just give you a number; it provides an attribute with specific steps to fix your score (e.g., “Delete 12 unavailable entities to gain +5 points”).
Smart Filtering: It’s designed to ignore “legitimate” sleepers like buttons or scenes so your score stays accurate.
Proactive Maintenance: It keeps you on top of backups and critical updates.

Join the “Race to 100”

I’ve released the reference implementation as a simple YAML template.

Get the code here: (GitHub - D-N91/home-assistant-global-health-score: The open standard for Home Assistant instance health monitoring. · GitHub)

How to participate:

Copy the haghs.yaml from the repo.
Add the Gauge card to your dashboard.
Post a screenshot of your score below! I’m currently sitting at a 87. Can anyone hit a perfect 100?

I have also submitted this as an official Architecture Proposal to see if we can get this logic integrated natively into Home Assistant Core. If you like the idea, a “Star” on GitHub would help show the devs there is community interest!

denzo · January 23, 2026, 2:55pm

TheFes · January 27, 2026, 1:48pm

You could make this a template blueprint. If you make changes/fixes to the templates people can just re-import it, and the config for the user will be easier, as they just have to provide the variables.

Somewhere in the future they will even be able to do it from the GUI. Then you can guide the entity selection using selectors.

Mariusthvdb · January 27, 2026, 2:07pm

fun project

though the thresholds for the DB are somewhat arbitrary…

there should be some weighing those imho. as long as the available disk space is fine, who cares about the db size? I mean mine is 3596.2 so deep in the penalty score but only at 6 % sensor.disk_use_percent_home…

have to check what Zombie entities are really.
o I see: | selectattr('state', 'in', ['unavailable', 'unknown'])

ok I didnt filter those yet, so thats going to take some work. most unavailable s are set in the UI explicitly though, not sure if they count in these templates.

denzo · January 29, 2026, 5:08pm

thanks for the suggestion! actually, i’ve already taken this a step further. haghs has evolved from a simple template into a full custom integration (custom component) with a native config flow.

this means you can already do exactly what you described: install it via hacs and use the ui setup mask with entity selectors to map your sensors. moving it to a proper integration allows for much deeper logic, better performance, and the “advisor” engine which would be hard to maintain in a blueprint.

check out the latest version on github, i’d love to hear your thoughts on the ui setup!

denzo · January 29, 2026, 5:13pm

that’s a fair point about disk space, but the db penalty isn’t actually about storage capacity—it’s about i/o performance. even if you have a 2tb ssd, a large database increases i/o wait times, slows down backups, and makes history/logbook loading sluggish. it’s more about “recorder health” than “disk capacity.” however, customizable thresholds are on the roadmap for exactly this reason, so users with high-end hardware can adjust the limits.

regarding the zombies: you’re right, filtering them manually via templates is a pain. that’s exactly why i implemented the haghs_ignore label support. you don’t have to write any code—just tag any device or entity in the ui with that label, and the integration automatically excludes it from the calculation. it makes cleaning up the score much easier than managing complex regex filters.

Mariusthvdb · January 29, 2026, 5:37pm

Made me wonder though , why are the zombies bad at all, or rephrase , count against health.

Also, having over 400/600, I dont think we should list them in the attribute.

That is worse for the system in itself

Corey_Johnson · January 30, 2026, 5:46pm

I cannot seem to find this update that it is referencing… is it logged in more detail anywhere?

Corey_Johnson · January 30, 2026, 7:49pm

I doubt I can get much better, maybe into the mid 70’s - it’s running on i5 4 cores with 16GB ram and like 97 GB of storage but I just installed Music Assistant and Voice w/local TTS and AI.

ajfriesen · January 31, 2026, 8:17am

Suggestion:

Instead of percentages values of usage, you should rather use the real pressure values from Linux:
These actually tell you, how much of your processes are waiting for CPU, memory or io.

Here is a good description of PSI:

80% disk space warning on a 2 tb disk is pointless.
You could make it staggered or use a fix value which at least should be available.

denzo · February 11, 2026, 9:51am

hi. great questions. zombies count against the score because they represent maintenance debt. an unavailable entity often means a broken automation, a dead battery, or a zigbee device that lost its route. these create noise in your logs and make your system less predictable. it is about hygiene, if you dont need it, remove it. if it is seasonal, use the haghs_ignore label.

regarding the attribute size: while the dashboard card uses collapsible rows to stay clean, the underlying state machine still has to carry that 400+ entity string. for v2.2, i will implement a cap on the attribute list to prevent state bloat, while keeping the total count accurate. thanks for pointing out the impact on system performance.

denzo · February 11, 2026, 9:56am

hi. haghs checks all entities in the update domain. if the advisor is nagging you but you dont see anything in the main update notification, check settings > system > updates.

sometimes updates are marked as ‘skipped’ or are hidden because of pending dependencies. haghs still sees these as ‘pending maintenance debt’. if it is a legacy update you cannot perform, you can use the haghs_ignore label on that specific update entity to stop it from affecting your score. v2.2 will actually list the specific update name in the attributes to make this easier to track.

denzo · February 11, 2026, 10:48am

this is excellent feedback.

regarding psi: i will look into how we can incorporate psi values into the score for v2.2, possibly as an optional advanced metric for those who have the sensors configured.

regarding disk space: i agree. for the next update i will look into changing the logic to a staggered approach or a minimum absolute threshold (e.g., warning only if less than 10gb or 15% remains, whichever is more sensible).

thanks for pushing the technical depth of this project.

ajfriesen · February 11, 2026, 11:25am

regarding psi: i will look into how we can incorporate psi values into the score for v2.2, possibly as an optional advanced metric for those who have the sensors configured.

I added PSI values in Home Assistant OS 16.3

I also worked to get PSI information into the systemmonitor integration, but that is still ongoing. Not sure if that can help you:

github.com/home-assistant/core

Add Pressure Stall Information (PSI) to Systemmonitor integration

dev ← ajfriesen:psi

opened 10:03PM - 08 Sep 25 UTC

ajfriesen

+708 -112

## Proposed change I want all Home Assistant users to be able to check if t…heir system is bound by any particular resource. Especially memory, but also IO and CPU. Used memory is a very bad metric to make decisions on. The system could use more than 99% of memory and could be totally fine or overloaded. Memory is often shared, then there is cache, buffers,etc. Used memory is good memory, and makes it hard to use it as a constraining measure. Then there is OOM, but then it is too late. With PSI for memory, we can check if the system was or is about to be bottlenecked by memory, cpu or IO. Pressure Stall Information (PSI) is a relatively new metric from the Linux Kernel. I can be found at `/proc/pressure/{cpu,memory,io}` Example: ``` some avg10=0.00 avg60=0.00 avg300=0.00 total=376 full avg10=0.00 avg60=0.00 avg300=0.00 total=85 ``` The `some` statistic gives the percentage of time some (one or more) tasks were delayed due to a lack of resources, for example, a lack of memory. The `full` metric indicates the percentage of time in which all tasks were delayed by lack of resources, i.e., the amount of completely unproductive time. A high full number indicates a loss of overall throughput – the total amount of work done decreases due to lack of resources. The `total` absolute stall time (in us) is tracked and exported as well, to allow detection of latency spikes which wouldn’t necessarily make a dent in the time averages, or to average trends over custom time frames. Sources: - https://facebookmicrosites.github.io/psi/docs/overview - https://www.kernel.org/doc/html/v6.12/accounting/psi.html ## Type of change - [ ] Dependency upgrade - [ ] Bugfix (non-breaking change which fixes an issue) - [ ] New integration (thank you!) - [x] New feature (which adds functionality to an existing integration) - [ ] Deprecation (breaking change to happen in the future) - [ ] Breaking change (fix/feature causing existing functionality to break) - [ ] Code quality improvements to existing code or addition of tests ## Additional information - This PR fixes or closes issue: fixes # - This PR is related to issue: - https://github.com/home-assistant/operating-system/pull/4279 - Link to documentation pull request: TBD - Link to developer documentation pull request: - Link to frontend pull request: ## Checklist - [x] The code change is tested and works locally. - I had to build the my own HA OS, since PSI was just merged into dev. But could run my changes as a custom component and did get all pressure values. I tested by installing the esphome builder and built a few configs and could see cpu, memory and io pressure values go up here and there. - [x] Local tests pass. **Your PR cannot be merged unless tests pass** - [x] There is no commented out code in this PR. - [x] I have followed the [development checklist][dev-checklist] - [x] I have followed the [perfect PR recommendations][perfect-pr] - [x] The code has been formatted using Ruff (`ruff format homeassistant tests`) - [x] Tests have been added to verify that the new code works. If user exposed functionality or configuration variables are added/changed: - [x] Documentation added/updated for [www.home-assistant.io][docs-repository] https://github.com/home-assistant/home-assistant.io/pull/40798 If the code communicates with devices, web services, or third-party tools: - [ ] The [manifest file][manifest-docs] has all fields filled out correctly. Updated and included derived files by running: `python3 -m script.hassfest`. - [ ] New or updated dependencies have been added to `requirements_all.txt`. Updated by running `python3 -m script.gen_requirements_all`. - [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description. To help with the load of incoming pull requests: - [ ] I have reviewed two other [open pull requests][prs] in this repository. [prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure [dev-checklist]: https://developers.home-assistant.io/docs/development_checklist/ [manifest-docs]: https://developers.home-assistant.io/docs/creating_integration_manifest/ [quality-scale]: https://developers.home-assistant.io/docs/integration_quality_scale_index/ [docs-repository]: https://github.com/home-assistant/home-assistant.io [perfect-pr]: https://developers.home-assistant.io/docs/review-process/#creating-the-perfect-pr

Corey_Johnson · February 11, 2026, 7:58pm

Thanks - I found it. It was a manual integration reporting an update available and I did not have it as an entity on my normal view for those type of things.

Still surprised at this rating - 86% on system with 4 CPU Cores with 16GB ram and 100GB storage at 49% full.
Seems to be CPU Load as I hover at 13-15% load with all the integrations and add-ons.

denzo · February 12, 2026, 8:56am

this is huge news, thank you for the heads-up. having psi natively in haos 16.3 and soon in the systemmonitor integration makes the roadmap for haghs v2.2 much cleaner.

instead of building custom file-parsers, we can now aim to pull these metrics directly from the core entities once your pr is merged. this is exactly the kind of standardization i was hoping for. i will keep a close eye on your pr—this will definitely be the gold standard for the haghs hardware score.

denzo · February 12, 2026, 9:09am

yes, the current 10% cpu threshold is quite strict for your setup. v2.2 will fix this by switching to psi (pressure stall information). instead of raw usage, we’ll measure actual resource ‘pressure,’ making the score much fairer for powerful hardware. check out the roadmap on r/haghs for more details.

Tosiman · February 13, 2026, 4:34pm

Hello there! Very cool idea! I have installed the integration myself and got a score of 85%. I think it would be a good idea to add more sensors to the Global health score. In my opinion these sensors should also be considered into the overall health score:

CPU Temperature
Raspberry Pi Power Supply Checker or similar since many users are running HA on their PI’s
Amount of repairs the system is showing

brywithawhy · March 1, 2026, 2:48am

Spent the day cleaning up zombies, ignoring seasonal items, and shrinking my database from 34GB to 72MB (yes, those units are correct, had to use VACUUM to get it to work)

Was getting excited as my score kept going up, but now everything reports fully optimised and only has a score of 86%.

How can I achieve 100% if nothing is reported?

Taipan · March 1, 2026, 10:54pm

I have followed the steps in this post and at https://github.com/D-N91/home-assistant-global-health-score to get HAGHS installed, but I am stuck at this point:

I assume that haghs.yaml is the YAML code posted on github that begins with this:

type: vertical-stack
cards:
  - type: gauge
    entity: sensor.system_ha_global_health_score
    name: HAGHS
    needle: true

And I assume that I should copy all that code to my configuration.yaml file?

However, I don’t have any dashboard entries already in my configuration.yaml and this code looks incomplete. There should be something about lovelace and dashboards - is that correct?

Could some kind person please guide me as to exactly what I need to do to get this into my dashboard?