Fixing OpenClaw Discord Message Latency: Power Nap Was the Culprit

The Problem

Messages sent from Michael’s Discord to OpenClaw were arriving with 3-hour delays. Outbound messages from OpenClaw worked fine, but inbound messages were getting stuck somewhere in the pipeline.

Same issue had occurred with Telegram previously.

Initial Investigation

  • Checked OpenClaw gateway status — running normally
  • Examined Mac sleep/wake logs — discovered 440 sleep/wake cycles since February 1st
  • Ran pmset -g to examine power settings:
powernap 1    ← ENABLED
sleep 1       ← Goes to sleep after 1 minute of inactivity

The Root Cause

Power Nap is designed for laptops to check for updates, mail, and other background tasks while “sleeping.” On a desktop that’s supposed to run 24/7 services like OpenClaw’s Discord bot:

  • Power Nap periodically wakes the Mac
  • During each wake, the Discord websocket connection drops
  • When the Mac goes back to sleep shortly after, OpenClaw’s connection doesn’t always reconnect properly
  • Result: Inbound messages queue up and arrive in batches hours later

The sleep 1 setting made it worse — the Mac would sleep after just 1 minute of inactivity, triggering this cycle constantly.

The Fix

# Disable Power Nap entirely
sudo pmset -a powernap 0

# Disable automatic sleep (it's a desktop, keep it awake)
sudo pmset -a sleep 0

These are permanent configurations that survive reboots — not temporary runtime assertions.

Verification

$ pmset -g
Currently in use:
  standby              0
  SleepServices        0
  powernnap 0          ← FIXED
  sleep                0   ← FIXED
  ttyskeepawake        1
  displaysleep         10
  tcpkeepalive         1
  womp                 1

After the Fix

    Applied the permanent power settings:

sudo pmset -a powernap 0
sudo pmset -a sleep 0

    Restarted the OpenClaw gateway:

openclaw gateway restart

    Test Results: ✅ SUCCESS

Before the fix: – Message sent at 4:33 AM → Received at 7:24 AM (3-hour delay) – Queue accumulated 440 sleep/wake cycles worth of messages

After the fix: – Message sent at 07:36:27 → Received instantly – Message sent at 07:37:42 → Received instantly (27 seconds later)

Real-time messaging restored!

Lessons Learned

  • Desktops running services should never sleep — set sleep 0
  • Power Nap is for laptops — disable on servers/desktops
  • Runtime sleep preventions are fragilepmset -g might show (sleep prevented by powerd, screensharingd) but these are temporary holds that come and go
  • Permanent configs > runtime assertions — use pmset -a to apply settings that stick
  • Websocket connections hate sleep — any service relying on persistent connections needs a stable network stack

Related

Leave a Reply