{"record":{"id":"6f837bd6e79c8e5f","repo":"louislam/uptime-kuma","slug":"request-timed-out","errorCode":null,"errorMessage":"Request timed out","messagePattern":"Request timed out","errorType":"exception","errorClass":"Error","httpStatus":null,"severity":"error","filePath":"server/monitor-types/rabbitmq.js","lineNumber":101,"sourceCode":"\n        try {\n            const res = await axios.request(options);\n            log.debug(\n                \"monitor\",\n                `[${monitor.name}] Axios Response: status=${res.status} body=${JSON.stringify(res.data)}`\n            );\n\n            if (res.status === 200) {\n                log.debug(\"monitor\", `[${monitor.name}] Node ${nodeInfo} is healthy`);\n                // Success - return without error\n            } else if (res.status === 503) {\n                throw new Error(res.data.reason);\n            } else {\n                throw new Error(`${res.status} - ${res.statusText}`);\n            }\n        } catch (error) {\n            if (axios.isCancel(error)) {\n                throw new Error(\"Request timed out\");\n            } else if (error.response) {\n                // Re-throw with the original error message if it's already formatted\n                throw error;\n            } else {\n                throw new Error(error.message);\n            }\n        }\n    }\n}\n\nmodule.exports = {\n    RabbitMqMonitorType,\n};\n","sourceCodeStart":83,"sourceCodeEnd":115,"githubUrl":"https://github.com/louislam/uptime-kuma/blob/6b5ea0155793e666666745fb8d6fef1e829543a2/server/monitor-types/rabbitmq.js#L83-L115","documentation":"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.","triggerScenarios":"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.","commonSituations":"Slow or unreachable node, network latency, RabbitMQ management API overloaded, or an overly tight timeout relative to the response size.","solutions":["Raise the monitor's timeout/interval to allow the management API to respond.","Confirm network reachability and latency to the node's management port (15672).","Check RabbitMQ node CPU/memory; an overloaded node answers slowly.","If one node is consistently slow, remove it from the list or fix its load."],"exampleFix":"// before\nmonitor.timeout = 5;   // seconds, too low for slow node\n// after\nmonitor.timeout = 30;","handlingStrategy":"retry","validationCode":"// Ensure the per-node timeout is reasonable relative to interval.\nfunction tuneTimeout(monitor) {\n  const minTimeout = 5; // seconds\n  if (!monitor.timeout || monitor.timeout < minTimeout) {\n    monitor.timeout = Math.max(minTimeout, Math.floor(monitor.interval * 0.5));\n  }\n}","typeGuard":"function isFiniteTimeoutSeconds(t) { return typeof t === 'number' && Number.isFinite(t) && t > 0; }","tryCatchPattern":"try {\n  await checkSingleNode(monitor, baseUrl, nodeInfo);\n} catch (e) {\n  if (e.message === 'Request timed out') {\n    // retry once with a longer timeout, then mark DOWN\n  }\n}","preventionTips":["Size the axios timeout to the slowest acceptable management response.","Alert on repeated timeouts distinct from auth/HTTP errors.","Co-locate Uptime Kuma with the RabbitMQ nodes to cut latency."],"tags":["rabbitmq","timeout","network"],"backgroundTag":null,"analyzedSha":"6b5ea0155793e666666745fb8d6fef1e829543a2","analyzedAt":"2026-08-12T23:42:12.959Z","schemaVersion":2},"datasetVersion":"2026-08-13T04:17:16.726Z"}