HA frequently accessing checkonline.home-assistant.io

[renatoyamane]

Describe the issue you are experiencing

Reported on HA Core, but the bot didn't assign it to any developer...

https://github.com/home-assistant/core/issues/152118

Home Assistant represents 5% of DNS Queries in my network.

The loop of queries are: TWICE at the same time --> ONCE after 3 minutes --> TWICE at the same time after 7 minutes

Doesn't make sense to make TWO queries at the same time.

Why not just ONCE every 10 minutes?

Home Assistant Cloud is disabled; Analytics are disabled.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Steps to reproduce the issue

Check the DNS Queries in your network

Anything in the Supervisor logs that might be useful for us?

It's repeating this every 1 hour:

2025-09-11 13:09:39.939 INFO (MainThread) [supervisor.resolution.check] Starting system checks with state running
2025-09-11 13:09:39.939 INFO (MainThread) [supervisor.resolution.checks.base] Run check for ipv4_connection_problem/system
2025-09-11 13:09:39.940 INFO (MainThread) [supervisor.resolution.checks.base] Run check for security/core
2025-09-11 13:09:39.940 INFO (MainThread) [supervisor.resolution.checks.base] Run check for multiple_data_disks/system
2025-09-11 13:09:39.940 INFO (MainThread) [supervisor.resolution.checks.base] Run check for disk_lifetime/system
2025-09-11 13:09:39.946 INFO (MainThread) [supervisor.resolution.checks.base] Run check for trust/supervisor
2025-09-11 13:09:39.959 INFO (MainThread) [supervisor.resolution.checks.base] Run check for pwned/addon
2025-09-11 13:09:40.010 INFO (MainThread) [supervisor.resolution.checks.base] Run check for dns_server_ipv6_error/dns_server
2025-09-11 13:09:40.011 INFO (MainThread) [supervisor.resolution.checks.base] Run check for free_space/system
2025-09-11 13:09:40.015 INFO (MainThread) [supervisor.resolution.checks.base] Run check for dns_server_failed/dns_server
2025-09-11 13:09:40.016 INFO (MainThread) [supervisor.resolution.checks.base] Run check for docker_config/system
2025-09-11 13:09:40.017 INFO (MainThread) [supervisor.resolution.checks.base] Run check for disabled_data_disk/system
2025-09-11 13:09:40.017 INFO (MainThread) [supervisor.resolution.check] System checks complete
2025-09-11 13:09:40.017 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state running
2025-09-11 13:09:40.304 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
2025-09-11 13:09:40.305 INFO (MainThread) [supervisor.resolution.fixup] Starting system autofix at state running
2025-09-11 13:09:40.305 INFO (MainThread) [supervisor.resolution.fixup] System autofix complete

System information

System Information

version	core-2025.8.3
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
container_arch	aarch64
user	root
virtualenv	false
python_version	3.13.3
os_name	Linux
os_version	6.12.43-haos
arch	aarch64
timezone	Europe/London
config_dir	/config

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 16.2
update_channel	stable
supervisor_version	supervisor-2025.09.0
agent_version	1.7.2
docker_version	28.3.3
disk_total	28.0 GB
disk_used	4.9 GB
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	green
supervisor_api	ok
version_api	ok
installed_addons	File editor (5.8.0)

Dashboards

dashboards	3
resources	0
views	1
mode	storage

Network Configuration

adapters	lo (disabled), end0 (enabled, default, auto), docker0 (disabled), hassio (disabled), veth21ce7ab (disabled), vethfe04509 (disabled), veth2650370 (disabled), veth828c871 (disabled), veth29f4e27 (disabled), vethf5ecc56 (disabled)
ipv4_addresses	lo (127.0.0.1/8), end0 (192.168.6.10/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), veth21ce7ab (), vethfe04509 (), veth2650370 (), veth828c871 (), veth29f4e27 (), vethf5ecc56 ()
ipv6_addresses	lo (::1/128), end0 (fe80::b84d:bf0d:eaef:5b41/64), docker0 (fe80::bc1e:32ff:fee3:e471/64), hassio (fe80::30c9:bfff:fe0b:63a6/64), veth21ce7ab (fe80::202d:c4ff:fe46:bf2a/64), vethfe04509 (fe80::444f:69ff:fe22:13ea/64), veth2650370 (fe80::b064:f0ff:fe79:b7d5/64), veth828c871 (fe80::a4db:a4ff:fe7c:4a5c/64), veth29f4e27 (fe80::2084:62ff:fe09:73f4/64), vethf5ecc56 (fe80::8488:13ff:fe70:dd93/64)
announce_addresses	192.168.6.10, fe80::b84d:bf0d:eaef:5b41

Recorder

oldest_recorder_run	15 August 2025 at 15:40
current_recorder_run	9 September 2025 at 22:09
estimated_db_size	65.61 MiB
database_engine	sqlite
database_version	3.48.0

Supervisor diagnostics

No response

Additional information

No response

[PW999]

I noticed the same behavior and got curious. If you look at the logs from my AdGuard instance, it becomes more obvious what happens:

Every 10 minutes, on the 1 minute mark, there are two A record lookups. Every 10 minutes, on the 8 minute mark, there are 2 AAAA record lookups.

So, there seem to be 2 different jobs running to check online connectivity. The double DNS lookups are also visible in wireshark:

Right after the A record lookup I can see an HTTP GET call

After the AAAA lookup I see nothing, I can confirm that from within VSCode I can't curl over ipv6, which is probably because I have IPv6 disable in HASS.

What is also weird is that it's an HTTP GET, while the code suggest it should be a HEAD instead.

//edit: did a bit of extra searches and it seems like NetworkManager is also doing a connectivity check: https://github.com/home-assistant/operating-system/blob/e15d99bc2b4e075dd23e7bccd6e95cc73daa855c/buildroot-external/rootfs-overlay/etc/NetworkManager/NetworkManager.conf#L18 . So maybe the NetworkManager check is what keeps Home Assistant happy.

[agners]

Yeah we have two connectivity check active, the one running in Supervisor, which essentially tells us if connectivity works in containers (which use the CoreDNS DNS service), and the other being on the host end, NetworkManager.

I can't tell you really why there are multiple queries though. The Supervisor code should only really cause one query from what I can tell. Maybe this is an artifact of CoreDNS and/or systemd-resolved or NetworkManager itself.

[PW999]

Is my assumption correct that the GET call is from resolvd and that the supervisor requests a AAAA record and fails to do the HEAD call, but that the connectivity check does not fail because systemd says the network is up? If so I should probably make another bug ticket since that is probably not great either.

[agners]

Is my assumption correct that the GET call is from resolvd and that the supervisor requests a AAAA record and fails to do the HEAD call, but that the connectivity check does not fail because systemd says the network is up?

I don't think that resolved reaches out using http. The GET call is from NetworkManager's connectivity check implementation. It seems its using libcurl and no explicit method is defined, which then should default to GET.

Only since ~July we enable IPv6 by default (see https://github.com/home-assistant/supervisor/pull/6029). So if your installation is very recent, then yes Supervisor might make AAAA requests.

All in all, in my tests things work as they should: If I "break" NetworkManager connectivity, host connectivity stops working, and is detect accordingly. If I break Supervisor connectivity, then this connectivity check fails. If you want something fixed, I need to exactly understand under what condition something is misbehaving, so that we can reproduce and fix it.

[PW999]

Okay so if that's the case then my tcpdump fails to capture IPv6 calls and everything works fine :) . Only oddity is that it does every DNS call twice (and not only the checkonline one).

[renatoyamane]

Only oddity is that it does every DNS call twice (and not only the checkonline one).

Mine has the same behaviour as yours, as you can see on the screenshot of my initial report.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[renatoyamane]

Do I need to create a new bug report just because the bot decided to stale this one? 🤔

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[woiwoiwoiwoi]

Just would like to mention that I am also affected by this and would prefer for the issue not to be closed.