louislam/uptime-kuma · error · Error

Request timed out

Error message

Request timed out

What it means

axios exposes isCancel(error) for requests aborted via a CancelToken or timed out by axios's own timeout. The catch in checkSingleNode tests axios.isCancel first and maps it to a stable 'Request timed out' message, abstracting away axios's internal cancel object. This is the per-node timeout path.

Source

Thrown at server/monitor-types/rabbitmq.js:101

        try {
            const res = await axios.request(options);
            log.debug(
                "monitor",
                `[${monitor.name}] Axios Response: status=${res.status} body=${JSON.stringify(res.data)}`
            );

            if (res.status === 200) {
                log.debug("monitor", `[${monitor.name}] Node ${nodeInfo} is healthy`);
                // Success - return without error
            } else if (res.status === 503) {
                throw new Error(res.data.reason);
            } else {
                throw new Error(`${res.status} - ${res.statusText}`);
            }
        } catch (error) {
            if (axios.isCancel(error)) {
                throw new Error("Request timed out");
            } else if (error.response) {
                // Re-throw with the original error message if it's already formatted
                throw error;
            } else {
                throw new Error(error.message);
            }
        }
    }
}

module.exports = {
    RabbitMqMonitorType,
};

View on GitHub (pinned to 6b5ea01557)

Solutions

1. Raise the monitor's timeout/interval to allow the management API to respond.
2. Confirm network reachability and latency to the node's management port (15672).
3. Check RabbitMQ node CPU/memory; an overloaded node answers slowly.
4. If one node is consistently slow, remove it from the list or fix its load.

Example fix

// before
monitor.timeout = 5;   // seconds, too low for slow node
// after
monitor.timeout = 30;

// Ensure the per-node timeout is reasonable relative to interval.
function tuneTimeout(monitor) {
  const minTimeout = 5; // seconds
  if (!monitor.timeout || monitor.timeout < minTimeout) {
    monitor.timeout = Math.max(minTimeout, Math.floor(monitor.interval * 0.5));
  }
}

function isFiniteTimeoutSeconds(t) { return typeof t === 'number' && Number.isFinite(t) && t > 0; }

try {
  await checkSingleNode(monitor, baseUrl, nodeInfo);
} catch (e) {
  if (e.message === 'Request timed out') {
    // retry once with a longer timeout, then mark DOWN
  }
}

When it happens

Trigger: The HTTP request to a RabbitMQ node exceeded the configured axios timeout and was cancelled. The options passed to axios.request carry the timeout derived from monitor settings, and exceeding it produces a cancel that the catch translates.

Common situations: Slow or unreachable node, network latency, RabbitMQ management API overloaded, or an overly tight timeout relative to the response size.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• Connection to Docker daemon timed out.
• All ${errors.length} nodes failed because ${errors.join("; "
• ${error.message}
• TLS Connection failed: ${message}
• Invalid Docker response, is it Docker really a daemon?

AI-assisted analysis of louislam/uptime-kuma@6b5ea01557 (2026-08-12). Data as JSON: /api/errors/6f837bd6e79c8e5f. Report an issue: GitHub.