Schedule API Workflow on List mistakenly uses 100% capacity. Why?

I have found that the Schedule API Workflow on List process instantly loads the server CPU to 100%. Even on Professional and Dedicated plans. Then I get a message that the application has been using the maximum capacity for some minutes.

For example, I need to process a list of 80000 rows and remove entries with certain parameters. In fact, one action is performed for each record. But if I process these records with the Schedule API Workflow on List, even at 1-second intervals, the maximum server CPU usage is 100%. One record per second… What is busy, is not clear.

At the same time, if you build a manual workflow, which goes through the records one by one, the processor is at rest (0% utilization). The surprising difference, even though workflow has an extra step to restart the loop and track the loop exit parameters it is still faster and more stable.

I have a question, why does a standard workflow that is supposed to solve a simple enumeration of records causes maximum capacity utilization? How to solve this problem?

1 Like

Bubble can process a maximum list size of 10,000 list items. If you are indeed using Schedule API Workflow on List, then Bubble is trying to take 10,000 of your 80,000 and utilizing CPU to load the list up for processing. That process of loading up that first 10,000 is the cause of the problem and why you hit 100% CPU immediately. When you do Schedule API recursively, it only loads 1 item at a time then moves to the next - Thus why the CPU stays almost at 0%.

You solve the problem by using Schedule API and making it recursive vs. using Schedule API Workflow on List.


Thank you for your reply. About the limits, I thought about that too. So I ran Schedule API Workflow on List on a smaller numbers, 1000, 500, 200. Nothing changes, the load is maximum.

If you run Schedule API recursively, you get Schedule on List function is absolutely useless and even harmful for the work of the application. This is weird. I think Bubble should pay attention to this.

Submit a bug ticket – If the load is maximum at all times, they can take a look.

1 Like

Yeah, I had the same issue. Like said, the only way to make it consistent it is to make a recursive backend workflow.

Example Workflow
Texts (List)
Iterator (Number)

then just retrieve info by: Texts item # Iterator > Do your magic…
To go to the next one simply call the workflow but increase the iterator by 1 each time.
Make sure to check if iterator <= texts:count to not go outside the range

This is understandable, so I did. I was more interested in why the standard process doesn’t work correctly.

Thank you all.
I’ll send them a bug report.

No idea man, I wasted 2 months going crazy with Schedule On List action…

I have so many complaints about the “Schedule API on a list” workflow. To me it’s useless since it slams your app at 100% capacity, then it can just give up at anytime it wants because they deem your app “too busy” even though as soon as they cancel it in the background your app sits at 0% (a perfect time to continue the workflow). Even the Bubble guys recommend “Schedule API on a list” only for things 50-100 things in size. And they admit it’s not reliable for anything higher than that.

I do recursive but I actually do like 10-20 of the same thing in each cycle which is WAY faster than what people say doing 1 by 1. For example if I want to change 1000 things, I send the list of 1000 things to the workflow, then I have Make changes to a thing:item #1, then step 2 is Make changes to a thing:item #2, and so on all the way to item #10. Then I have the workflow schedule itself:minus list, from item#1 until item#10. Then at least it does 10 things in each loop. Or you could even try 20 things.

I’ve talked about why don’t they just do their own internal recursive workflow behind the scenes when you do the on a list workflow and let it hit near-max capacity, but if some other workflows come up just make the API lower priority and lower the speed of the API workflow a little bit if other parts of the app need it.


This topic was automatically closed after 14 days. New replies are no longer allowed.