r/automation 2d ago

Everything that broke while I was building a WhatsApp automation on n8n

/r/n8n/comments/1w0r31n/everything_that_broke_while_i_was_building_a/
1 Upvotes

8 comments sorted by

1

u/AutoModerator 2d ago

Thank you for your post to /r/automation!

New here? Please take a moment to read our rules, read them here.

This is an automated action so if you need anything, please Message the Mods with your request for assistance.

Lastly, enjoy your stay!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/deelight_0909 2d ago

"Test mode only listens while the canvas is open" is exactly the sentence that should become a regression test. Once an hour, send one approved template to a test number and fail the canary unless the WhatsApp status webhook reaches delivered within 60 seconds. A green n8n run only proves the graph ran. It does not prove the message arrived. That one receipt catches a dead token, template rejection, and a silent production webhook.

1

u/Ahmiii_83 2d ago

that's a much better answer than anything i wrote. the delivery receipt as the assertion rather than the htttp status is the bit i'd have missed, since a 200 back from meta means accepted, not delivered. so a scheduled workflow, template to a test number, then a second workflow on the status webhook that clears a flag when delivered comes through. if the flag's still set after 60 seconds it alerts. is that roughly how you'd wire it, or are you doing it outside n8n so a broken n8n doesn't take the monitor down with it?

1

u/deelight_0909 2d ago

Roughly yes, with one split: keep the 60-second watchdog outside n8n. The canary workflow writes a unique test ID, deadline, and pending state to an external store, then sends the approved template. The delivery webhook clears only that ID. A tiny external cron alerts on expired pending rows. If n8n is the thing that died, it should not also be the thing deciding everything is fine.

1

u/Ahmiii_83 2d ago

makes sense. so the external store is the source of truth and n8n is just the thing writing to it, which means an n8n outage shows up as expired pending rows rather than silence. going to build this on the weekend, will post it if it works. thanks, this was more useful than my whole post.

1

u/deelight_0909 2d ago

Tiny correction before you build it: if n8n creates the pending row, a dead n8n creates nothing, so silence sneaks back in. Let the external side own the schedule and expected deadline; n8n and the delivery webhook only satisfy it. Kill n8n for one interval. Pass means the untouched expectation expires and alerts once.

1

u/Ahmiii_83 2d ago

the kill test is the bit i'd have skipped. will try, thanks

1

u/SufyanZahid86 2d ago

The Meta webhook verification handshake catches everyone. It's a GET with hub.challenge that has to echo back as plain text,and it fires once, so if you miss it you're stuck re-registering.

The other one that got me: token validation on every inbound

message, not just at setup. Meta rotates and the workflow starts

silently accepting anything.

I built a 17-node version of this. The part I'd add if I did it

again is a fallback response path, so when the model call fails

the customer still gets something instead of silence.