Stop Uptime Checks from Flooding Your DNS Logs

Reconstruct the request rate

Take one representative monitor and record its configured interval, timeout, redirects, address-family behavior, and retry policy. Then compare the observed requests from its source address during a quiet window. Twenty-six checks every thirty seconds already mean 74,880 scheduled checks per day. Two record types or additional hostnames can increase DNS traffic without any retry storm.

This arithmetic is a baseline, not a claim about how every Uptime Kuma version resolves names. Confirm the requests on your network. A redirect to a different hostname, a notification provider, and an external database each add their own lookups.

Locate the cache that is actually in use

Separate three quantities: requests sent by the monitoring process, requests received by its resolver, and queries that resolver sends upstream. A cached answer can still appear in the resolver's client query log. TTL does not necessarily mean an application will make no more requests until that TTL expires.

Inspect the resolver configured inside the runtime, not only on the Docker host. Docker documents different DNS paths (opens in a new tab) for default and custom networks. A container's resolution path may therefore differ from the interactive shell used to investigate the problem.

Use a short, scoped capture or resolver counters and avoid collecting unrelated household or customer browsing history. Compare the same time window on both sides of the resolver.

Reduce load while preserving the failure signal

Increase polling intervals only where the resulting detection delay remains acceptable. Stagger checks to avoid synchronized bursts. Use a supported caching resolver close to the monitoring workload when measurements show upstream work is the problem. Re-test after the change with the cache warm, cold, and unavailable.

Do not extend cached data indefinitely to make graphs quieter. Address changes and failover can require fresh resolution. Include cache restart behavior in the experiment so an apparently efficient setup does not create a DNS burst every time the host reboots.

An IP-pinned request is useful for diagnosis: it can separate an origin problem from a resolver problem while retaining the expected hostname for TLS and HTTP. It is not a complete replacement for the public hostname check. curl's connection controls (opens in a new tab) can help compare those paths without changing the application's normal endpoint.

Verify the tradeoff

Record before-and-after client queries, upstream queries, lookup latency, and failure detection time. Change a controlled DNS fixture to a second address and confirm the hostname-based monitor follows it as intended. Then break the test resolver and verify that DNS failure remains visible.

If the issue is mainly oversized logs, adjust retention and aggregation after confirming operational needs. Hiding individual entries can reduce storage; it cannot fix an unhealthy resolution path. Keep enough sampled evidence to distinguish cache behavior from a future retry loop.