The difference is the callback URL, and once you see it the whole class of "triggers do not work self-hosted" problems collapses into one thing.
An incoming-message trigger is not polling. When you activate it, your instance registers a webhook with the provider — it tells the provider "call this URL when a message arrives". The provider then makes an inbound HTTP request to that URL from the public internet.
On the vendor's hosted version, your instance has a public HTTPS URL and it knows what that URL is, so registration works and the provider can reach it.
Self-hosted, two things go wrong:
1. Your instance advertises the wrong URL. By default it builds the callback URL from its own idea of where it lives, which is often localhost, a container name, or an internal address. It registers that with the provider. The provider stores it, dutifully calls it, and reaches nothing — or refuses to accept it in the first place, which is your intermittent registration error.
The fix is the setting that tells the instance its public base URL. Nearly every self-hostable automation platform has one, usually an environment variable, and it exists precisely for this. Set it to the exact public HTTPS URL the outside world uses, restart, then deactivate and reactivate the trigger — this is the step people miss. The registration is made once at activation and does not update itself when you change the config. A stale registration points at your old wrong URL forever.
2. The provider cannot reach you. Even with the right URL advertised, the request has to arrive:
- Public reachability. The URL must be reachable from the internet, not just from your network. Test it from outside — a phone on mobile data is the quickest honest test.
- HTTPS with a valid certificate. Most providers require TLS and will not accept a self-signed certificate. A self-signed cert makes the browser complain; it makes the provider silently drop the registration.
- Standard ports. Several providers only call port 443 and will reject a URL with a custom port at registration time.
- Provider IP restrictions. If you have geo-blocking or an allowlist at your edge, the provider's servers may be blocked. This produces the pure-silence case: registration succeeds, nothing ever arrives.
How to tell the two apart in one minute. Look at the trigger node in the editor — it shows you the webhook URL it is going to register. If that URL contains localhost or an internal hostname, it is problem one and nothing else matters yet. If it is your correct public URL, it is problem two, and the next step is your reverse proxy access log: make the provider send a test message and see whether a request arrives at all. Request in the log means the problem is downstream of the proxy. No request means it never got to you, and that is DNS, firewall, TLS or the provider's own restrictions.
One more, since your description mentions it activating and then nothing arriving: most of these platforms use a different webhook URL in test mode than in production, and the test URL only listens while you have the editor open with the node listening. Activating the workflow switches to the production URL and re-registers. If you tested in the editor and it worked, then activated and it stopped, that is this.