HTTP(S) - Keyword monitors repeatedly hit Axios 30 s timeouts for two reachable targets; isolated requests from the same container succeed

I have found these related issues/pull requests

I found these related, but not identical, reports:

• #275, Lots of 'timeout of 48000ms exceeded' during the day, but the site is still up? — similar Axios timeout while a separate check succeeds, but a different (Windows/Docker Desktop) environment and timeout value.
• #4534, Ability to use curl as a backend for HTTP(s) monitor — reports Node.js HTTP timeouts for a target while curl succeeds. It is a closed feature request rather than this exact bug.
• #3752, stuck monitor after read ETIMEDOUT — not the same behavior: my monitors retry and recover; they do not get stuck.

️ Security Policy

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

Description

Two HTTP(S) - Keyword monitors repeatedly produce timeout of 30000ms exceeded on their first attempt, then recover on a retry. This has continued after:

• updating Uptime Kuma from 2.5.0 to 2.5.4;
• restarting the Uptime Kuma service/container;
• simplifying both monitored URLs;
• using a 30 s request timeout, 60 s retry interval, and 5 minute heartbeat interval.

The two public targets are reachable and return the expected keyword quickly from the running Uptime Kuma container when checked in an isolated process. A 20-request Axios control test per target, using the monitor's timeout, redirect limit, status-code rule, and browser-like Accept header, completed with 20/20 keyword matches and no errors. Maximum observed control-test times were 147 ms and 93 ms.

This is not a broad instance-wide problem. The instance has 55 monitors. In the latest 24-hour window, only three monitors had any pending heartbeats; these two were the only monitors with 10 or more pending heartbeats, and every other monitor had at most one.

I do not yet have a minimal deterministic standalone reproduction. I am reporting the production behavior and the controls above in the hope of learning which additional diagnostics would distinguish a long-lived Kuma-process/Axios behavior from target-specific network handling.

Is there a recommended way to capture request-level diagnostics for just these monitor IDs without logging response bodies or credentials? In particular, I would like to determine why the long-lived monitor process times out while an isolated Axios process in the same container succeeds.

Reproduction steps

1. Run Uptime Kuma 2.5.4 as described in the deployment environment below.

2. Create these two HTTP(S) - Keyword monitors:

   Monitor	URL	Keyword	Interval	Retry interval	Retries	Request timeout
   LHB iServ	https://lhb-do-edu.de/iserv/auth/login	IServ	300 s	60 s	2	30 s
   LHB webUntis Server	https://lhb-do.webuntis.com/WebUntis/	Leopold-Hoesch-BK Dortmund	300 s	60 s	4	30 s

3. For both monitors, use GET, validate TLS, accept status codes 200-299, allow up to 10 redirects, and do not configure a proxy or cache busting. The iServ monitor has no custom headers. The webUntis monitor has one explicit User-Agent header.

4. Let the monitors run for at least a few hours.

Expected behavior

Both targets should normally be marked UP directly. In particular, successful isolated Axios checks from the same running container complete in well under one second, so routine 30-second request timeouts are unexpected.

Actual Behavior

The first attempt frequently becomes PENDING because Axios reaches its 30-second timeout. The configured retry then usually succeeds, so there are no corresponding DOWN events.

Latest 24-hour heartbeat counts:

Monitor ID	UP rows	PENDING rows	DOWN rows
1 — LHB iServ	262	131	0
11 — LHB webUntis Server	256	160	0

Uptime-Kuma Version

2.5.4

Operating System and Arch

Debian GNU/Linux 13 (trixie), x86_64

Browser

Not applicable. This is a server-side HTTP(S) keyword monitor; no browser monitor is involved.

️ Deployment Environment

• Runtime Environment:
  • Docker: Not installed; Uptime Kuma runs rootful under Podman 5.4.2.
  • Docker Compose: Not applicable.
  • Portainer (BE/CE): Not installed.
  • MariaDB: Not used.
  • Node.js: Version 22.22.3 (LTS: Yes; bundled in the Uptime Kuma container).
  • Kubernetes (K3S/K8S): Not installed.
• Database:
  • SQLite: Embedded.
  • MariaDB: Not applicable.
• Database Storage:
  • Filesystem: Linux ext4 (/dev/sda1).
  • Storage Medium: Non-rotational provider-backed virtual disk (ROTA=0; presented as /dev/sda).
• Uptime Kuma Setup:
  • Number of monitors: 55.

Relevant log output

[MONITOR] WARN: Monitor #1 'LHB iServ': Pending: timeout of 30000ms exceeded | Max retries: 2 | Retry: 1 | Retry Interval: 60 seconds | Type: keyword
[MONITOR] WARN: Monitor #11 'LHB webUntis Server': Pending: timeout of 30000ms exceeded | Max retries: 4 | Retry: 1 | Retry Interval: 60 seconds | Type: keyword


In the latest 24-hour window, there were 131 matching timeout log entries for monitor #1 and 159 for monitor #11. A few `ECONNRESET` events were observed earlier, but the persistent pattern is Axios's 30-second timeout.