Yep. Consider: you can build a damn reliable & resilient Webhook handler out of a few lines of PHP or Lua, ready to accept a fairly heavy load, zero dependencie

Yep. Consider: you can build a damn reliable & resilient Webhook handler out of a few lines of PHP or Lua, ready to accept a fairly heavy load, zero dependencies, and only default-available packages for most any distro or BSD (anything where nginx or Apache2 with standard modules is available by default) and without tweaking the config at all. You can be live in hours, or even inside a single hour if you want to cowboy it up pretty hard, and despite not taking a lot of care, the webhook-handling part of your service probably won't get you woken up at night with a everything's-on-fire support call (what it does with the data might, of course). Logging? Trivial and standard. Service management? It's the OS' default service definition for a web server daemon, and that's it. Config and deployment? So tiny it'd be nearly no work to document it in a run-once shell script, if you don't have anything fancier at hand. Operationally, it doesn't get much simpler. "Is it working?" checks? You can test it with curl, from any address that's able & allowed to talk to it. With long-polling, now you're managing a custom daemon, basically. That's a big step down in reliability-by-default, and a bunch more work to do it right. In either case, you'll be looking at more work if you want to check any kind of log on the other end for missed messages, but that looks pretty similar for either, and not all systems need that level of accuracy (and if they do, they probably need even more and this whole thing is Doing It Wrong)