louislam/uptime-kuma · error · Error

${res.data.reason}

Error message

${res.data.reason}

What it means

RabbitMQ's management API returns HTTP 503 when the node/cluster is considered unhealthy and includes a `reason` field in the JSON body (e.g. a resource alarm). checkSingleNode special-cases 503 to surface that reason directly rather than the generic status text. So the message is whatever the RabbitMQ HTTP API put in res.data.reason.

Source

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

            signal: axiosAbortSignal((monitor.timeout + 10) * 1000),
            // Capture reason for 503 status
            validateStatus: (status) => status === 200 || status === 503,
        };

        log.debug("monitor", `[${monitor.name}] Checking node ${nodeInfo}: ${baseUrl}`);

        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. Resolve the alarm reported in `reason`: free disk space, raise vm_memory_high_watermark, or clear the alarm with `rabbitmqctl clear_resource_alarm <name>`.
2. Inspect cluster state: `rabbitmqctl status`, `rabbitmqctl cluster_status`, and the management UI overview.
3. Confirm the node being queried is the one in alarm; rotate through each node URL.
4. Tune limits (disk_free_limit, vm_memory_high_watermark) so transient load does not trip 503.

Example fix

# before
reason: "memory resource alarm"
# after
rabbitmqctl set_vm_memory_high_watermark absolute=2GB && rabbitmqctl clear_resource_alarm memory

// Pre-flight: call the aliveness endpoint; if 503, surface the reason early.
async function preflightRabbitNode(monitor, baseUrl) {
  const res = await axios.get(`${baseUrl}/api/aliveness-test/%2F`, { auth: { username: monitor.rabbitmqUsername, password: monitor.rabbitmqPassword } });
  if (res.status === 503 && res.data?.reason) {
    throw new Error(res.data.reason);
  }
}

function hasResourceAlarmReason(data) { return !!data && typeof data.reason === 'string'; }

try {
  await checkSingleNode(monitor, baseUrl, nodeInfo);
} catch (e) {
  if (/resource alarm|disk|memory/i.test(e.message)) {
    alertOps('RabbitMQ resource alarm: ' + e.message);
  }
  throw e;
}

When it happens

Trigger: axios.request returns status 503 with a JSON body containing `reason`. Common reasons include resource alarms (disk or memory), node not running, or maintenance mode. The branch at rabbitmq.js:95 throws res.data.reason verbatim.

Common situations: Disk alarm (disk_free < disk_free_limit), memory alarm (mem_above watermark), node paused, or the cluster in a degraded state where the management plugin still answers 503.

Related errors

• ${res.status} - ${res.statusText}
• The oauth config is invalid. ${e.message}
• Your JSON body is invalid. ${e.message}
• ${bean.msg}, but keyword is ${present|not} in [${data}]
• RabbitMQ Nodes must be valid JSON: ${e.message}

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