#High latency on openclaw message send — text 25s+, attachment 30-90s

1 messages · Page 1 of 1 (latest)

bright smelt
#

Hi everyone! I'm running OpenClaw on a VPS (Contabo) to send WhatsApp notifications from a web app. I'm experiencing significant delays and looking for optimization advice.

📐 Setup

VPS: Contabo Linux, OpenClaw installed with WhatsApp + Telegram channels configured
Gateway running via PM2 (openclaw-gateway)
I built a Python HTTP wrapper (oc-send-api.py) on port 18800 that receives requests from my Vercel app and calls the CLI:

openclaw message send
--channel whatsapp
--target +628xxx
--message "..."
--json
For file attachments, I add --media /path/to/file
Exposed via Cloudflare Tunnel → Vercel calls it as an API
🐛 Issues

Issue 1 — Text message latency (25s+ timeout)
Simple text messages sometimes take >25 seconds for openclaw message send to return. My subprocess timeout is 25s, causing a 504 back to the frontend. The message eventually gets delivered, but the CLI doesn't return in time.

Issue 2 — Attachment latency (30–90 seconds)
Sending a file with --media takes 30–90 seconds. I've worked around this with fire-and-forget (background thread), but the delay is still felt by the end user.

Issue 3 — Gateway frequent restarts
PM2 shows openclaw-gateway has restarted 12+ times. I suspect each restart causes the WA session to reconnect, making the next few sends slow. Is there a way to make the gateway more stable?

Issue 4 — Inbound webhook to Supabase latency
I have a hook (wa-to-supabase) that fires on message:received and does a POST to my Supabase endpoint. Sometimes there's a noticeable delay between a user sending a WA message and it appearing in our app's inbox. Is the hook fired synchronously or async? Any way to reduce this latency?

What I've already tried
Added --channel whatsapp flag (required since I have multiple channels)
Switched text sends to sync + 25s timeout, attachment sends to background thread (fire-and-forget)
Added a serial worker queue to prevent concurrent openclaw processes
Running gateway via PM2 for auto-restart

#

Is there a non-CLI way to trigger sends? e.g., an internal HTTP API or SDK that openclaw-gateway exposes, so I don't have to spawn a new process for every message?
What causes the CLI to take 25+ seconds for a simple text? Is it waiting for a delivery receipt? Is there a flag to send without waiting for confirmation?
Any flag to send fire-and-forget from the CLI — return immediately after queuing the message, without waiting for WA to confirm delivery?
Best practice for --media attachment sends? Is there a way to pre-upload or cache files to reduce per-send time?
How to prevent openclaw-gateway from restarting? Any known stability issues or recommended config to keep the WA session alive long-term?
For inbound hooks — is message:received fired before or after OpenClaw processes the message? Any way to reduce hook-to-webhook latency?

bright smelt
#

@icy basin please help..

icy basinBOT
#

Ri, first thing: please paste:

openclaw --version

That said, a few likely issues jump out:

  1. Don’t wait on openclaw message send from the frontend path.
    That CLI call is synchronous: process startup → config/plugin load → gateway RPC → WhatsApp Web send/upload → response. For customer-facing UX, return 202 Accepted immediately, enqueue the send, and update delivery state later. Your fire-and-forget direction is the right architecture.

  2. Attachments being 30–90s can be normal-ish for WhatsApp Web, especially large files. OpenClaw reads/prepares the media, then WhatsApp Web/Baileys uploads it. Resize/compress aggressively and treat attachment sends as async jobs.

  3. PM2 restarts are the scary part.
    A restart reconnects the WhatsApp Web session, and the next send can be slow. Also make sure you don’t have two gateways fighting each other — PM2 plus systemd/OpenClaw service.

    Please run:

# 
openclaw status --all
openclaw gateway status --deep
openclaw channels status --probe
pm2 logs openclaw-gateway --lines 200

Docs: https://docs.openclaw.ai/gateway/troubleshooting

  1. Prefer the managed Linux service over PM2 unless you have a strong reason. On Linux:
openclaw gateway install
systemctl --user enable --now openclaw-gateway.service
openclaw gateway status