What happens with scheduled (or dependent) workflows when server problems or outages occur?

Thanks, @JohnMark , it’s helpful knowing that others are in the same boat. I may have missed it in the Bubble docs and posts, but I haven’t seen much about how one might manage or be informed of these workflow breaks - even though I’m sure many people share this concern.

We’ve done a few things that we believe would help, such as the following, but I’d be interested in hearing any other solutions from experienced Bubble developers:

• Use recursive workflows to process any lists, as opposed to ‘schedule API on a list’, which seems to cause errors for many users. And we add at least a 10-second interval before rescheduling the same WF.
• Storing all ID numbers for scheduled APIs in a relevant table (e.g., a scheduled survey’s API ID is stored in that survey’s table, so we can see when it’s missing). This allows us to quickly check that an expected API has actually been scheduled.
I’m assuming this is what you mean by ‘keep a history of all scheduled workflows’, although I’d love to hear what others do to ensure all WFs are executed (or a way to be notified when this happens).
• Created a ‘SuperUser’ type (i.e., us) that reveals a dashboard with a list of potential errors. For example, during a stress test, we noticed that the ‘end date’ for an ‘active’ survey was earlier than the current date (i.e., a current survey should always end or close in the future). This occurred because a WF broke and subsequent surveys weren’t scheduled. So, we added a repeating group to this SuperUser group that searches for surveys with this problem, and emails us if count > 0.

I also came across your post about hiring someone who was able to code for recursive WFs, which seemed to improve performance and reliability. It’s nice to know the option is available:

Schedule API Workflow on List - failing for lists of 100+ items?

Thanks again,

-Chad

2 Likes