Multiple HTTP monitors with different intervals fail simultaneously despite target being 100% reachable from outside Kuma (curl, external host — never reproduces)

I have found these related issues/pull requests

Related issues

This appears related to (but not fully explained by) the following existing reports, which describe similar symptoms without a confirmed root cause:

#6040 — "ALL 200 monitors fail at the same time" (also tried scaling to 8 cores/16GB RAM without effect) #5245 — "Help with timeout-problems for http monitors" (monitor works fine immediately after alert) #4432 — "Very high response time causing request timeout on some monitors"

I spent a full day methodically ruling out every layer of my own infrastructure to narrow this down as much as possible before filing. Details below.

Description

Multiple independent HTTP(S) monitors intermittently fail with timeout of Xms exceeded, often several at the same time despite having different check intervals (20s / 60s). This happens even though:

The target servers are reachable and respond correctly during the exact same time window when tested manually from the same host running Kuma. An external VM outside the local network, polling the same URLs every 5s over an 8-minute window during an active Kuma failure period, received HTTP 200 on 100% of ~450 requests with response times consistently under 100–300ms. A second, fully independent Uptime Kuma instance, running outside my network and monitoring the exact same domains, shows 100% uptime with no failures at all — over the same time period where the original instance keeps showing intermittent failures. This is the same software, just running elsewhere, which to me is the strongest evidence that this isn't a target-server or network issue. DNS resolution (measured with nslookup in a loop, 246 samples over ~15 minutes) stayed consistently under 60ms, no outliers. The reverse proxy (nginx / Nginx Proxy Manager) access/error logs show no errors, timeouts, or unusual entries correlating with the Kuma failure timestamps — only benign trust_forwarded_proto warnings. Router/firewall (UniFi UCG Ultra) IPS/IDS exclusion for the Kuma host's IP was added — partial improvement only, not a full fix. Router firmware was downgraded from UniFi OS 5.1.33 to 5.1.31 (the last version before a suspected regression) and the exact same failure pattern persisted, unchanged. DNS was rewritten locally (AdGuard Home) so the monitored domains resolve directly to the internal reverse-proxy IP, completely bypassing NAT hairpinning / the router's WAN path. The failures still occurred identically — traffic never left the LAN/host during these failures. As a further step, all local subnets involved in the request path (Kuma's own subnet, the reverse-proxy subnet, the Proxmox host subnet, and a fourth internal subnet) were explicitly excluded from the router's IPS/IDS (Suricata-based) inspection entirely, in both directions. The failure pattern remained unchanged. Kuma container CPU was raised from 1 to 2 cores — partial improvement, not a full fix.

This effectively rules out: DNS, the target web servers, the reverse proxy, the router/firewall/NAT path, the ISP, and the general LAN. The one constant across all failures is that Kuma itself is the process performing the check.

Observed pattern Affects only HTTP(S) monitors with a extern tag pointing to various public domains behind the same reverse proxy (different backends). Multiple monitors with different intervals (e.g. 20s and 60s) fail within the same 1–2 second window, suggesting a shared bottleneck inside the Kuma process rather than per-monitor network issues. Failures are always timeout of Xms exceeded, never a connection-refused or DNS error. A manual curl loop (1 request/sec) run directly on the same host/container, targeting the same domains, never showed a single failure over several minutes — including during periods where Kuma was actively failing on the very same domain. docker stats on the Kuma container showed no CPU spike at the moment failures were logged (though this was not captured with sub-second granularity during an active failure). Log excerpt (redacted domains) 2026-09-13T10:27:23+02:00 [MONITOR] WARN: Monitor #4 'Proxmox - Extern': Failing: timeout of 16000ms exceeded | Interval: 20 seconds | Type: http | Down Count: 0 2026-09-13T10:28:02+02:00 [MONITOR] WARN: Monitor #2 'Reverse Proxy Manager': Pending: timeout of 16000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 20 seconds | Type: http 2026-09-13T10:28:02+02:00 [MONITOR] WARN: Monitor #31 'Webseite (www)': Pending: timeout of 16000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 20 seconds | Type: http 2026-09-13T10:28:03+02:00 [MONITOR] WARN: Monitor #13 'Vaultwarden': Pending: timeout of 48000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 60 seconds | Type: http

Three monitors with different intervals (20s, 20s, 60s) and different backend targets all begin failing within the same second.

Environment Uptime Kuma version: 2.5.4 Node.js version: 22.22.3 Deployment: official Docker image, running inside an unprivileged LXC container (Proxmox), 2 vCPU / 4GB RAM allocated to the LXC, container itself well within resource limits (docker stats showed <10% CPU, ~280MB RAM at time of testing) ~9 monitors tagged extern, mostly HTTP(S) type, intervals between 20s and 60s, timeouts between 16–48s Reverse proxy: Nginx Proxy Manager (Docker), separate host DNS: self-hosted AdGuard Home Router: UniFi UCG Ultra (tested on both UniFi OS 5.1.31 and 5.1.33 — no difference in the failure pattern) Steps to reproduce

Unfortunately not reliably reproducible on demand — occurs sporadically, roughly every 10–20 minutes, affecting a semi-random subset of the extern-tagged monitors each time. Happy to provide additional diagnostics/logs if useful.

Expected behavior

HTTP(S) checks should not intermittently time out when the exact same request, made independently and concurrently from the same host via curl, consistently succeeds within ~100–300ms.

Additional notes

Given that multiple monitors with staggered intervals fail within the same second, and that a plain curl from the same machine never reproduces the issue even during an active Kuma failure, this looks like it could be related to Node.js's HTTP client connection pooling / DNS resolution behavior (dns.lookup vs dns.resolve, or undici/axios connection reuse) under concurrent load from multiple monitors, rather than an actual network-level problem. Willing to help debug further if a maintainer has ideas on what to capture (e.g. NODE_DEBUG, event loop lag monitoring, etc.).

️ Security Policy

• I have read and agree to Uptime Kuma's Security Policy.

Description

This appears related to (but not fully explained by) the following existing reports, which describe similar symptoms without a confirmed root cause:

• #6040 — "ALL 200 monitors fail at the same time" (also tried scaling to 8 cores/16GB RAM without effect)
• #5245 — "Help with timeout-problems for http monitors" (monitor works fine immediately after alert)
• #4432 — "Very high response time causing request timeout on some monitors"

I spent a full day methodically ruling out every layer of my own infrastructure before filing this. Summary of what was tested, all without changing the failure pattern:

• Manual curl from the exact same host/container as Kuma, same target, during an active Kuma failure — always succeeds (100–300ms).
• A second, fully independent Uptime Kuma instance running outside my network, monitoring the same domains — shows 100% uptime over the same period the internal instance keeps failing.
• An external VM (outside my network) polling the same URLs every 5s for 8 minutes during an active failure period — 100% success (~450/450 requests).
• DNS resolution timing (246 samples via nslookup loop) — consistently under 60ms, no outliers.
• Reverse proxy (Nginx Proxy Manager) access/error logs — no errors or timeouts correlating with Kuma's failure timestamps.
• Router firmware downgrade (UniFi OS 5.1.33 → 5.1.31) — no change.
• DNS rewritten locally so monitored domains resolve directly to the internal reverse-proxy IP, fully bypassing NAT hairpinning and the router's WAN path — no change.
• All local subnets involved in the request path excluded from the router's IPS/IDS inspection entirely, both directions — no change.
• Kuma container CPU raised from 1 to 2 cores — partial improvement only, not a full fix.

The one constant across every failure is that Kuma itself is the process performing the check. Given that monitors with staggered/different intervals (20s and 60s) fail within the same 1–2 second window, this looks like it could be related to Node.js's HTTP client connection pooling or DNS resolution behavior (dns.lookup vs dns.resolve, or undici/axios connection reuse) under concurrent load from multiple monitors, rather than an actual network-level problem. Willing to help debug further if a maintainer has ideas on what to capture (e.g. NODE_DEBUG, event loop lag monitoring, etc.).

Reproduction steps

Unfortunately not reliably reproducible on demand — occurs sporadically, roughly every 10–20 minutes, affecting a semi-random subset of the extern-tagged monitors each time.

Setup: ~9 HTTP(S) monitors tagged extern, intervals between 20s and 60s, all pointing to different domains/backends behind the same reverse proxy (Nginx Proxy Manager). Just let it run and watch the monitor list — some subset will intermittently go into "Pending"/"Down" with timeout of Xms exceeded, then recover on the next check.

Happy to provide additional diagnostics/logs if useful.

Expected behavior

HTTP(S) checks should not intermittently time out when the exact same request, made independently and concurrently from the same host via curl, consistently succeeds within ~100–300ms — and when a second, fully independent Kuma instance monitoring the same domains from outside the network shows 100% uptime over the same period.

Actual Behavior

Multiple independent HTTP(S) monitors intermittently fail with timeout of Xms exceeded, often several at the same time despite having different check intervals (20s / 60s).

Log excerpt (redacted domains): 2026-09-13T10:27:23+02:00 [MONITOR] WARN: Monitor #4 'Proxmox - Extern': Failing: timeout of 16000ms exceeded | Interval: 20 seconds | Type: http | Down Count: 0 2026-09-13T10:28:02+02:00 [MONITOR] WARN: Monitor #2 'Reverse Proxy Manager': Pending: timeout of 16000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 20 seconds | Type: http 2026-09-13T10:28:02+02:00 [MONITOR] WARN: Monitor #31 'Webseite (www)': Pending: timeout of 16000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 20 seconds | Type: http 2026-09-13T10:28:03+02:00 [MONITOR] WARN: Monitor #13 'Vaultwarden': Pending: timeout of 48000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 60 seconds | Type: http

Three monitors with different intervals (20s, 20s, 60s) and different backend targets all begin failing within the same second.

This is the same behavior described in #6040, #5245, and #4432, but I've gone further to rule out the environment — see the "Additional notes" I'll add as a comment, or scroll up if there's a free-text field, covering: external curl loop (100% success during active Kuma failures), a second independent Kuma instance outside the network (100% uptime on the same domains), DNS timing, reverse proxy logs, full IPS/IDS exclusion for all involved subnets, and a router firmware downgrade — none of which changed the pattern.

Uptime-Kuma Version

2.5.4

Operating System and Arch

Debian GNU/Linux (unprivileged LXC on Proxmox VE), x86_64

Browser

Not directly relevant — issue is server-side (monitor checks), not UI-related. Tested via the Kuma web UI on current Chrome.

️ Deployment Environment

• Runtime Environment:
  • Docker: official louislam/uptime-kuma image
  • Node.js: v22.22.3 (bundled in image)
• Database:
  • SQLite: Embedded
• Database Storage:
  • Filesystem:
    • Linux: ext4
• Host: unprivileged LXC container on Proxmox VE, 2 vCPU / 4GB RAM allocated (container itself well within resource limits — docker stats showed <10% CPU, ~280MB RAM at time of testing)
• Network: self-hosted, behind Nginx Proxy Manager (reverse proxy) and AdGuard Home (DNS), UniFi UCG Ultra router (tested on UniFi OS 5.1.31 and 5.1.33 — no difference in the failure pattern)

Relevant log output

2026-09-13T10:27:23+02:00 [MONITOR] WARN: Monitor #4 'Proxmox - Extern': Failing: timeout of 16000ms exceeded | Interval: 20 seconds | Type: http | Down Count: 0
2026-09-13T10:28:02+02:00 [MONITOR] WARN: Monitor #2 'Reverse Proxy Manager': Pending: timeout of 16000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 20 seconds | Type: http
2026-09-13T10:28:02+02:00 [MONITOR] WARN: Monitor #31 'Webseite (www)': Pending: timeout of 16000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 20 seconds | Type: http
2026-09-13T10:28:03+02:00 [MONITOR] WARN: Monitor #13 'Vaultwarden': Pending: timeout of 48000ms exceeded | Max retries: 3 | Retry: 1 | Retry Interval: 60 seconds | Type: http

Note: Three monitors with different intervals (20s, 20s, 60s) and different backend targets all begin failing within the same second — suggesting a shared bottleneck inside the Kuma process rather than per-monitor network issues.