FAILED status

[Andrea-1976]

about and hour ago all my sessions are stuck in STARTING. Then after a while they go into FAILED status.

I have the latest version NOWEB (2026.7.1 PLUS)

I tried restarting the service, but makes no difference.

Does anyone else have this problem or knows how to solve it?

Thanks

[ionutzu]

I have the EXACT same issue. Anyone has a solution for this?

Thnak you,

[anonimcakep]

yes, me too

[Horbatenko]

+1

[Cristianoiai]

+1

[matheusrramos97]

I fixed it by forcing the WhatsApp Web version inside the WAHA container.

Run:

docker exec waha-2 bash -c "sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\ version: [2, 3000, 1037641644],' /app/dist/core/engines/noweb/session.noweb.core.js"

Then restart the container.

After doing this, my sessions started working again instead of getting stuck in STARTING and then changing to FAILED.

This is just a temporary workaround until an official fix is released.

[rafasaru]

I fixed it by forcing the WhatsApp Web version inside the WAHA container.

Run:

docker exec waha-2 bash -c "sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\ version: [2, 3000, 1037641644],' /app/dist/core/engines/noweb/session.noweb.core.js"
Then restart the container.

After doing this, my sessions started working again instead of getting stuck in STARTING and then changing to FAILED.

This is just a temporary workaround until an official fix is released.

That worked for me, thank you

[Mahmoud-Skafi]

Fix for Dokploy / Docker Swarm deployments

Same thing here on 2026.7.1 NOWEB, running on Dokploy (Docker Swarm). Fixed it by pinning the WhatsApp Web version — Baileys needs it passed to makeWASocket, see WhiskeySockets/Baileys#2731.

The patch itself applies to any setup, but the persistence part below is Swarm/Dokploy specific — that's the bit that kept biting me.

Heads up before you do this: you lose your sessions. Every number needs a fresh QR scan. Back up your session DB first.

Patch:

sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\      version: [2, 3000, 1043857760],' \
  /app/dist/core/engines/noweb/session.noweb.core.js

Get the current build number from Baileys baileys-version.json. An outdated one fails exactly like no patch at all.

If you're on Docker Swarm or Dokploy the sed won't survive a restart — Swarm recreates the container from the image every time. Run it at startup instead.

Dokploy specifically: the Command field gets .split(" ") with no quote handling, so a sed one-liner shatters and breaks the container. Put it in Args, which is passed through as-is. Image is ENTRYPOINT ["/usr/bin/tini","--"] + CMD ["/entrypoint.sh"], so keep tini as PID 1:

Command:

/usr/bin/tini

Args:

["--", "/bin/sh", "-c",
 "sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\\      version: [2, 3000, 1043857760],' /app/dist/core/engines/noweb/session.noweb.core.js; exec /entrypoint.sh"]

Use Redeploy, not Start. Start only scales the existing service and won't pick up the new config — looks like nothing happened. Check it landed with docker inspect <container> --format '{{json .Args}}'.

Compose:

services:
  waha:
    image: devlikeapro/waha-plus:2026.7.1
    entrypoint: ["/usr/bin/tini", "--", "/bin/sh", "-c"]
    command:
      - >-
        sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\      version: [2, 3000, 1043857760],'
        /app/dist/core/engines/noweb/session.noweb.core.js;
        exec /entrypoint.sh

[JrGrecco]

Same symptom here, and we found the cause. It's the hardcoded WhatsApp Web version in the NOWEB engine.

Symptom: all NOWEB sessions dropped simultaneously, go STARTING → FAILED, restarting doesn't help, and no QR is ever generated. Logs loop like this:

session:xxx - connected to WA
session:xxx - not logged in, attempting registration...
session:xxx - connection errored {"trace":"Error: Connection Failure ... noise-handler.js decodeFrame"}
session:xxx - Connection closed due to 'Error: Connection Failure', reconnecting...
The socket connects fine, so it's not network or DNS. WhatsApp accepts the handshake and rejects the login. The QR never appears because the pairing reference comes from WhatsApp, so if login is refused there's nothing to render. Same root cause as WhiskeySockets/Baileys#2731.

Cause: NOWEB announces a fixed client version that WhatsApp now refuses. Ours was announcing 2.3000.1035920091 while WhatsApp was serving 2.3000.1044017588.

1. Check your own numbers:

what WhatsApp requires right now

curl -s https://web.whatsapp.com/sw.js | grep -oE 'client_revision[^,}]*'

what your WAHA announces

docker logs --tail 400 2>&1 | grep -o 'appVersion[^}]*}' | tail -1
If yours is lower, this is your problem. Do not use web.whatsapp.com/check-update?version=1&platform=web to compare, it's the legacy endpoint and returns 2.2413.51, which makes the current 2.3000.x look ahead. That misled us for hours.

2. Before touching anything, protect your pairings. Sessions that keep retrying and failing lose their credentials and will need a fresh QR. We lost 3 of 7 accounts this way while diagnosing. Stop every session that still shows me.id:

curl -X POST -H "X-Api-Key: $KEY" -H 'Content-Type: application/json'
-d '{"name":"SESSION_NAME"}' http://localhost:3000/api/sessions/stop
STOPPED survives a restart. FAILED may retry and burn the credential.

3. Apply the fix (replace and ):

F=/app/dist/core/engines/noweb/session.noweb.core.js

docker exec cp $F $F.bak

docker exec sed -i
'/markOnlineOnConnect: markOnlineOnConnect,/a\ version: [2, 3000, ],' $F

docker exec node --check $F && echo "syntax OK"

docker restart
4. Result on our side: sessions left FAILED immediately, QR generation came back, and the three accounts whose credentials we had protected returned to WORKING without needing a new QR.

Caveats:

Use docker restart, not docker compose up -d. The patch lives in the container filesystem and is lost whenever the container is recreated or the image is updated. Re-apply after any of those.
Upgrading WAHA does not fix this. Our outage started on 2026.5.1 and persisted after upgrading to 2026.7.1; only the version patch resolved it.
The WEBJS engine was unaffected. Another deployment of ours running WEBJS kept pairing normally throughout, which is what pointed us at the engine in the first place.
This is a workaround. The proper fix is Baileys' fetchLatestWaWebVersion() so the version isn't pinned at build time.

[JrGrecco]

fetchLatestBaileysVersion() fetches from the Baileys GitHub repo (Defaults/index.ts), not from WhatsApp, so it returns whatever version the Baileys maintainers last committed. That's exactly the value that went stale and caused #2191, so auto-detection would return the broken version and the fix would appear not to work.

fetchLatestWaWebVersion() reads client_revision from https://web.whatsapp.com/sw.js, which is what WhatsApp actually serves. Measured during the outage: our NOWEB was announcing 2.3000.1035920091, web.whatsapp.com/sw.js returned 1044017588. Patching the compiled JS with the latter brought all sessions back immediately, including previously paired ones, with no re-scan.

Suggestion: try fetchLatestWaWebVersion() first and keep fetchLatestBaileysVersion() as the fallback, so there are two network sources before the bundled default.

[7vilanata]

What is the recommended action for users affected by this issue? Should we apply the temporary version patch manually, or is it safer to wait for the WAHA team to update the WhatsApp Web version in an official release?

[jaderweb]

I fixed it by forcing the WhatsApp Web version inside the WAHA container.

Run:

docker exec waha-2 bash -c "sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\ version: [2, 3000, 1037641644],' /app/dist/core/engines/noweb/session.noweb.core.js"
Then restart the container.

After doing this, my sessions started working again instead of getting stuck in STARTING and then changing to FAILED.

This is just a temporary workaround until an official fix is released.

Perfect man, it worked here as well thank you

[martiGIT]

I fixed it by forcing the WhatsApp Web version inside the WAHA container.

Run:

docker exec waha-2 bash -c "sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\ version: [2, 3000, 1037641644],' /app/dist/core/engines/noweb/session.noweb.core.js"
Then restart the container.

After doing this, my sessions started working again instead of getting stuck in STARTING and then changing to FAILED.

This is just a temporary workaround until an official fix is released.

Works for me! Thanks

[mrjay59]

Fix for Dokploy / Docker Swarm deployments

Same thing here on 2026.7.1 NOWEB, running on Dokploy (Docker Swarm). Fixed it by pinning the WhatsApp Web version — Baileys needs it passed to makeWASocket, see WhiskeySockets/Baileys#2731.

The patch itself applies to any setup, but the persistence part below is Swarm/Dokploy specific — that's the bit that kept biting me.

Heads up before you do this: you lose your sessions. Every number needs a fresh QR scan. Back up your session DB first.

Patch:

sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\ version: [2, 3000, 1043857760],'
/app/dist/core/engines/noweb/session.noweb.core.js
Get the current build number from Baileys baileys-version.json. An outdated one fails exactly like no patch at all.

If you're on Docker Swarm or Dokploy the sed won't survive a restart — Swarm recreates the container from the image every time. Run it at startup instead.

Dokploy specifically: the Command field gets .split(" ") with no quote handling, so a sed one-liner shatters and breaks the container. Put it in Args, which is passed through as-is. Image is ENTRYPOINT ["/usr/bin/tini","--"] + CMD ["/entrypoint.sh"], so keep tini as PID 1:

Command:

/usr/bin/tini

Args:

["--", "/bin/sh", "-c",
"sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\ version: [2, 3000, 1043857760],' /app/dist/core/engines/noweb/session.noweb.core.js; exec /entrypoint.sh"]
Use Redeploy, not Start. Start only scales the existing service and won't pick up the new config — looks like nothing happened. Check it landed with docker inspect <container> --format '{{json .Args}}'.

Compose:

services:
waha:
image: devlikeapro/waha-plus:2026.7.1
entrypoint: ["/usr/bin/tini", "--", "/bin/sh", "-c"]
command:
- >-
sed -i '/markOnlineOnConnect: markOnlineOnConnect,/a\ version: [2, 3000, 1043857760],'
/app/dist/core/engines/noweb/session.noweb.core.js;
exec /entrypoint.sh

after restart docker cointainer waha
session=EDN_237183 session=EDN_237183 trace=Error: Stream Errored (conflict)
at WebSocketClient. (file:///app/node_modules/@adiwajshing/baileys/lib/Socket/socket.js:796:18)
at WebSocketClient.emit (node:events:508:28)
at file:///app/node_modules/@adiwajshing/baileys/lib/Socket/socket.js:470:35
at processData (file:///app/node_modules/@adiwajshing/baileys/lib/Utils/noise-handler.js:126:13)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
at async Object.decodeFrame (file:///app/node_modules/@adiwajshing/baileys/lib/Utils/noise-handler.js:197:13)
at async WebSocketClient.onMessageReceived (file:///app/node_modules/@adiwajshing/baileys/lib/Socket/socket.js:447:9)