Notifications for spiking workload unit consumption

maybe adding an option to add a webhook can be helpful


Really appreciate you sharing your thinking here on what would be ideal.

One question I’m still sorting through is it feels like there are two different challenges here:

  1. Inexperienced developers who don’t even know they can get into trouble with recursive workflows (the newbies you describe)
  2. Experienced folks who want more granular controls and know enough to know that these would be useful (soft and hard caps, an API and/or webhook, etc)
    Obviously the ideal is to solve both of these! But I think they probably have different solutions since they’re solving different problems. Either way - I appreciate your candor and ideas here.

Hey @laura.oppenheimer

Happy to have up this thread and see people with the same need (not sure I can be happy for that lol)

As I suggest when we had talked about this, the first actionnable tool you can propose is a way to dynamicly monitor WU usage, with a simple webhook we can trigger to GET a wu usage from a date/time start and date/time end.

This could be a Quick win as we can :

  • set by our own a custom alert (email, sms, whatever) based on metrics we can choose
  • setup Stops in wf based on a parameter according to this webhook response we can store

Ok this is not solving the newbee issue (if there is no experienced bubbler in the dev team). To solve this a more reactive spike email/in app red alert will be nice + some hard way learning for them as we all had one day passed :rofl::rofl: but for that you can do nothing, no fix, just time… and pain!

+1 to make WU consumption accessible in back-end API workflows OR a webhook and
+1 @georgecollier’s comment on the hard limit exceeded landing page. It’s terrible UX to show the Bubble apps page when an app is over the limit.
When it happened to an app of mine it took me awhile to realize that it was happening for WU overages as I couldn’t imagine that Bubble would redirect to that page due to account overages (and instead thought that it was a DNS issue).

@bubble, Take the user to index and disable workflows. (yes, I know that just loading the index page requires WFs, but too bad, these are paying customers, Bubble, and it’s inexcusable to not load a web page so take a tiny tiny hit for the team…)

1 Like

Agreed. Let us be able to customize the look and content of the “over limit” page. It doesn’t need WFs, just content.

I think most Bubblers don’t hit their development WU limits so the “over limit” page can count towards that.

In my opinion, it would be more beneficial if subscribers received the total workload for the entire year upfront, rather than having it reset monthly. This way, we could better manage our resources, especially during months with varying workloads. For example, if I have 250,000 Work Units (WU) per month, multiplying it by 12 would give me a total of 3,000,000 WU for the year.

Additionally, it would be great to have the option to purchase additional workload without an expiry date. This flexibility would allow us to consume the workload as needed, without the pressure of it expiring at the end of each month.

I’ve noticed that due to the monthly reset, there’s a risk of losing unused WUs, and there isn’t currently a way to track WUs from previous months, such as from January 1st to January 30th.

@josh @emmanuel


+1 : purchase extra WU that are not burned at the end of the month and will be lost is not that fair :sob:


Did y’all know that the one time waiver thing is not actually a waiver of the WU overages!?! I never had to deal with this waiver business before Bubble notified me of overages 22 hours after they started and 15 hours after they were totally resolved (this reply above)

So the one-time waiver that Bubble is offering as a special dispensation for this insanity is to allow my customer to jump a tier up on the WU consumption add-on, which nearly any SaaS would allow at any time when a customer has overages (especially within the month it happened; e.g., I’ve done this on Zapier dozens of time)

So instead of an actual waiver for the one time overages, the proposal is to reduce the overage costs (not the entire monthly bill) by merely ~29%!!! (see image below)

They can call it whatever they want but it’s certainly not a waiver, it’s just basic customer service for a SaaS and should be allowed always (not one time) and is wholly inadequate as a resolution when Bubble is to blame for the overages.