[Feature Enhancement] Logs now provide additional insights for actions on a list

Hi everyone,

I’m Steve, a product manager here at Bubble for our Scale team. As a part of our broader goal of improving observability for large scale operations, I’m excited to share our latest update, which significantly enhances the server logs for actions on a list (this includes operations like modifying, deleting, copying, or scheduling workflows on a list).

The logs now capture important insights that can help with understanding outcomes and troubleshooting, including:

  • The number of items in the list to run on
  • The number of items successfully updated/scheduled
  • The criteria used to generate the list, including the evaluated values of any dynamic expressions used in the constraints
  • How long the action took to complete

Outcomes: understand the results from actions run on lists

Whether it’s admins doing bulk processing or users interacting with your app, the data in your app is changing all the time. Logs now contain critical information to help you figure out what happened — and why.

As an example, let’s say you want to delete all records older than 30 days, except for those you’ve flagged as “critical.” Historically, it could be difficult to validate the results for a Delete a list of things action when it ran on a long list, especially in dynamic environments where multiple users or workflows may be making updates concurrently.

As a part of this update, logs now offer additional details about the planned versus actual outcomes for each action on a list. Below is a screenshot of a log generated from our example scenario. The List to delete count conveys the number of things in the list. You can compare this number to the Successfully deleted count to validate that everything was deleted as expected.

Troubleshooting: identify issues with workflow logic

If things don’t go as planned, the logs now provide more information to help you confirm or correct the logic you used in your workflow. Specifically, the logs will show you the actual values that were used for generating the list to run on.

In our example, this means the logs include the value that was supposed to evaluate to “30 days ago.” If the evaluated value is something else (e.g., 30 minutes ago), then you know you need to correct the logic in the workflow.

Previously, you could only see evaluated values in the Bubble debugger when manually testing your app. Now, instead of needing to reproduce an issue in your test environment first, you can see all of the evaluated values logged from when the workflows‌ ran on your live site.

Looking Ahead - Observability

Observability is critical for having confidence in your application, especially as your app grows. It helps you validate when things are working as expected, and solve the problems when they’re not. Stay tuned: Our roadmap for 2024 includes more observability improvements to help you scale confidently on Bubble.

Steve and the Scale team


Really like this improvement.

I had a question on logs in general.

I have a faint memory that it used to give detailed HTTP request/response data. E.g. for an API call, it would share the parameters passed & the response received.

But I can’t seem to see that anymore

Was that changed recently?



You can access these options by clicking the Show Advanced button.

1 Like

Awesome. Can you guys please add a check all options to the logs? So we dont have to check all those boxes manually


For saving 5 seconds, turning on all the filters at the same time; show you overwhelming data, people get lots very soon.

With turning on HTTPS response/request its become a nightmare.

I do enable that. But the HTTP request/response used to have more data of the entire API call in them. Now it just has the header and not the body of the request…


Thanks for this.

I have a question regarding

In the example, I assume the API workflow was scheduled for some future time, and at the point of the developer implementing the workflow action to schedule the API workflow needed to add a parameter of the list items to delete, which seems to be a Do a Search for.

Does the Do a Search for happen at the time the API workflow got scheduled or at the time it runs? My question is around the concept of data always changing, so if the API workflow got scheduled on Feb 1st to run +10 days (so Feb 11) would the Do a Search list to run on get evaluated on Feb 1st or Feb 11?



This is great! Do you know what the current upper bound is for the number of things the actions on a list can handle? I know it’s been improved recently. It used to be around 100 things, based on the community posts.

I love all you can do to make it easier to build and debug complex apps with a lot of dependencies, thanks.

Best, Peter