It’s not a “not working” thing, it’s a time out thing. If the component that processes payload formatters is under load - mostly due to a sudden surge in uplinks mostly due to co-incidence, then they are more prone to timeout - currently set to 100ms.
This was an issue with v2 and became an issue with v3 about 200ms after it was made available to the community, some whom have 400KB+ globs of JS!
You don’t get the payload fields ie decoded_payload is empty - or has warnings.
I’d expect the server instances by region to be scaled appropriately - so we may have more powerful ones than you but all regions would be scaled to suit - so I’d expect it to happen anywhere.
I don’t have current stats as I haven’t migrated all of my tools and it sort of doesn’t effect me anyway as I turn it off for production use and for development use I don’t care.
Cool - MQTT is harder on the servers than Webhooks and confers no real benefits as QOS is set to 0 and a web server is very scalable all by itself.
I use server side whilst coding but deploy using my side decoder.
As I mentioned previously, having an intermediary comes with the benefit of being able to store “everything for ever” in a data store you can backup yourself so if a third party has a bad server day, you’re not entirely lost.
One other possibility is that Ubidots provides a mapping function - you could ask them for that so you have two options running at once - one here & one with them - it’s not an unusual issue so others may have had to swap out devices. And you can then send your data over to Ubidots directly but still have a Webhooks for your backup data store.