Fix: heartbeat-fail false positives due to /health returning HTML in OpenClaw 2026.x

[ether-btc]

Issue

The heartbeat-fail rule triggers false positives because the /health endpoint in OpenClaw 2026.2+ returns an HTML dashboard instead of JSON.

Root Cause

In newer OpenClaw versions, GET /health returns HTML (the dashboard page) instead of JSON response. The gateway client still expects JSON, causing heartbeat detection to fail.

Impact

• False "Gateway unresponsive" alerts
• Users receive critical alerts when gateway is actually healthy
• Affects any deployment using OpenAlerts with OpenClaw 2026.2+

Workaround (Current)

Use openclaw status instead of /health endpoint:

#!/bin/bash
# Gateway Health Check V2

# Check if gateway is running
if ! pgrep -f "openclaw" > /dev/null; then
    echo "ERROR: Gateway not running"
    exit 1
fi

# Check if we can get status
if openclaw status > /dev/null 2>&1; then
    echo "OK: Gateway healthy"
    exit 0
else
    echo "ERROR: Gateway not responding"
    exit 1
fi

Suggested Fix

Update the gateway watcher to use the SSE health event or openclaw status command instead of querying the /health HTTP endpoint directly.

---

Environment:

• OpenClaw: 2026.2.27
• OpenAlerts: 0.2.5
• Platform: Raspberry Pi 5 / Debian Bookworm

[Dev-Khant]

Hey for this issue ppenalerts does not use OpenClaw’s /health HTTP endpoint. It monitors the gateway only through a WebSocket connection (ws://127.0.0.1:18789).

It listens for heartbeat messages over that WebSocket. Alerts trigger only if multiple heartbeats are missed or if too much time passes without one.

The /health endpoint in the codebase belongs to OpenAlerts itself, not OpenClaw. So changes to OpenClaw’s /health response wouldn’t affect anything.

If you’re seeing “Gateway unresponsive” alerts, it’s likely a real WebSocket connection problem (token mismatch, wrong port, gateway not running, etc.).