Does anyone have recommendations for load testing an application? e.g. acting as a logged in User, clicking elements on pages, basic workflows etc?
I just use Claude or Codex. They can run automated tests like that for me. 
How do you set them up to do that on your bubble apps? That would be a cool tutorial to make.
@J805 , thanks very much for the input.
Can they run 25 concurrent Users? 100?
I’m not sure how many they can do at once. I’ve never tested it to that extent.
You should be able to do some of the testing through the browser so it doesn’t matter if it’s on Bubble or somewhere else.
I just wonder how many it can handle at one time. 
I also heard Playwright is pretty good too.
I think something like this could work.
Artillery and Playwright together
For Bubble, I would set it up like this:
- Create a set of Bubble test User accounts. Using Claude if you set up Bubbble so you can create users with their API.
- Have each virtual user open the Bubble app and log in normally.
- Click buttons, enter data, navigate pages, trigger workflows, etc.
- Ramp from perhaps 5 → 20 → 50 → 100 concurrent users.
- Watch Bubble → Logs → App Metrics while the test runs to see which searches/workflows are consuming WU.
One important Bubble-specific thing: enable Settings → General → Expose the option to add an ID attribute to HTML elements, then give important buttons/inputs IDs such as login-button, email-input, etc.
Thanks for the tips @J805 !
Plus one on the ID attributes, that saves a lot of pain with selectors.
One Bubble-specific thing worth flagging before anyone ramps to 100 concurrent users: the load test itself consumes real workload units. Every simulated session runs the same searches and workflows a real one would. Ramping 5 to 20 to 50 to 100 means paying for all of it, and if you have overage enabled you can find the test costs more than the problem it uncovered.
Testing against dev does not get you out of it either, since development usage counts against the same monthly allocation as live. Worth confirming on your own account before you plan the run.
Which points at a cheaper method. What you actually want to know is not whether Bubble survives 100 users, it is WU per user journey. So run 5 concurrent users through the flows you care about, then read App metrics for that window and divide. Now you have a cost per session, and you can extrapolate to any traffic level on paper instead of paying to simulate it. You also get the per-journey figure, which tells you which flow to optimise first.
Ramp to 100 afterwards if you still need the concurrency answer, but by then you know what the run will cost you.
Testing against the development version does not get you out of it. Database operations only incur WU in run-mode, not in the editor, but a load test runs in run-mode by definition, and development and live both count against the same monthly allocation.