You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I like uptime-kuma a lot for its simplicity and monitor my home server instances since one of the boxes started rebooting with intermittent kernel panics a few months back. Thanks to uptime-kuma, I was able to further investigate exact times of the outtages and finally pinpoint the problem.
Nevertheless, I have a "problem", but I do not know if it really is a bug, a fault on my side or just "by design". Monitoring has been active for months now, a mix of checking ping'ability of IPs/hostnames and availability of http(s) pages. This two-staged checking tells me if the instance is available and, in some cases, if the web-service it offers is accessible. When checking the IP/Hostname, this generates two DNS requests. One for the A, one for the AAAA record. Reasonable, all good.
But when checking for http(s), each check generates six DNS requests, which are always 15 seconds apart. So a check every 5 minutes does not sum up to only 12 DNS requests per hour, but ends up 72 times requesting DNS. Multiplied by the number of checked instances, this easily makes my uptime-kuma instance the top client for DNS requests each day. Since the 15 second interval seems a bit "set", I tried to find this value in the settings. It is the timeout value - but since the requests do not timeout, this can't be the problem, right? Furthermore, setting the timeout to any different value did not change the 15sec interval anyways.
Why does one check via http(s) generate six DNS requests, each consecutive request 15 seconds after the one before? Is this meant to be by design of checking http(s)?! Is my configuration wrong for this specific check?
📝 Error Message(s) or Log
No response
🐻 Uptime-Kuma Version
1.23.15
💻 Operating System and Arch
Raspbian Lite 64-bit based un Debian 12 bookworm
🌐 Browser
different Chrome revisions, firefox
🖥️ Deployment Environment
Runtime: Docker
Database: embedded
Filesystem used to store the database on:
number of monitors: about 20
The text was updated successfully, but these errors were encountered:
🛡️ Security Policy
📝 Describe your problem
I like uptime-kuma a lot for its simplicity and monitor my home server instances since one of the boxes started rebooting with intermittent kernel panics a few months back. Thanks to uptime-kuma, I was able to further investigate exact times of the outtages and finally pinpoint the problem.
Nevertheless, I have a "problem", but I do not know if it really is a bug, a fault on my side or just "by design". Monitoring has been active for months now, a mix of checking ping'ability of IPs/hostnames and availability of http(s) pages. This two-staged checking tells me if the instance is available and, in some cases, if the web-service it offers is accessible. When checking the IP/Hostname, this generates two DNS requests. One for the A, one for the AAAA record. Reasonable, all good.
But when checking for http(s), each check generates six DNS requests, which are always 15 seconds apart. So a check every 5 minutes does not sum up to only 12 DNS requests per hour, but ends up 72 times requesting DNS. Multiplied by the number of checked instances, this easily makes my uptime-kuma instance the top client for DNS requests each day. Since the 15 second interval seems a bit "set", I tried to find this value in the settings. It is the timeout value - but since the requests do not timeout, this can't be the problem, right? Furthermore, setting the timeout to any different value did not change the 15sec interval anyways.
Why does one check via http(s) generate six DNS requests, each consecutive request 15 seconds after the one before? Is this meant to be by design of checking http(s)?! Is my configuration wrong for this specific check?
📝 Error Message(s) or Log
No response
🐻 Uptime-Kuma Version
1.23.15
💻 Operating System and Arch
Raspbian Lite 64-bit based un Debian 12 bookworm
🌐 Browser
different Chrome revisions, firefox
🖥️ Deployment Environment
The text was updated successfully, but these errors were encountered: