Why Did Our Bubble.io Bill Grow? A Seven-Day Workload Audit
A practical seven-day audit that traces Bubble workload to its trigger, business value, recurrence, controls, and blast radius before you optimise or rebuild.
One workload incident added more than $1,400 to our Bubble.io bill. We found the source, but the cost kept accumulating while we worked out how to contain it. In our case, we could not stop only the offending workload without taking the whole application offline.
That is a founder observation from our own app, not a general claim about every Bubble incident. I published the figure and the control problem on X. We have not published the underlying billing records or the exact technical cause, so I will not manufacture either here.
The incident did expose a broader problem with reading a usage-based bill: the bill records work, not value.
Bubble defines workload as the server resources needed to host, run, and scale an app. Workload units aggregate activities such as database operations, workflows, and web requests. Bubble charges the work whether it came from valuable customer activity, an inefficient design, an internal error, or unwanted external traffic that caused the app to do server-side work. (Bubble: workload, pricing and workload FAQ)
The invoice therefore tells us that the server did work. It does not tell us whether the business wanted that work, whether it will happen again, or whether we had a safe way to stop it.
Before optimising the app or using the bill as an argument for migration, I would run a seven-day workload audit.
Why seven days
Seven days is long enough to catch weekday and weekend behaviour, recurring jobs, ordinary customer use, and at least some operational routines. It is short enough that a founder or small team can inspect the evidence while the details are still fresh.
It is not a statistically complete sample. A weekly audit can miss month-end processing, seasonal demand, rare imports, annual renewals, and incidents that did not recur during the window. The point is not to calculate a permanent average from one week. The point is to turn one opaque total into an attributable set of activities and unanswered questions.
Run the audit against a representative live period. Keep Development and Live separate: Bubble says both contribute to total usage, while its App metrics dashboard reports them separately. (Bubble: measuring workload)
Start with three records, not one
The audit needs three kinds of evidence.
1. The billing record. Record the app plan, included workload, any workload tier, whether overages were enabled, and the relevant billing period. Do not convert WU into money using an assumed rate: Bubble's published overage rate depends on whether a workload tier is attached, and commercial terms can change. Use the rate shown for the app and period being audited. (Bubble: pricing and workload FAQ)
2. App metrics. Use the historical charts to find the days, categories, pages, workflows, actions, and expressions responsible for the largest shares of workload. Bubble documents drill-down from aggregated usage to individual pages, workflows, elements, and expressions. (Bubble: activity types)
3. Server logs and operating evidence. Server logs show individual server-side tasks and their WU calculations. Pair them with deploys, imports, support tickets, integration events, campaign dates, and operator actions from the same period. The log tells you that something ran. The surrounding evidence helps explain why. (Bubble: Logs tab)
The purpose is reconciliation. If the bill rises but the corresponding work cannot be connected to a product or operating event, that gap is itself a finding.
The seven-day workload log
Create one row for each meaningful activity. Do not start with every individual log line. Start with the few activities that dominate the chart, then add representative normal use, background work, integrations, and anomalies.
Activity | Trigger and frequency | WU / cost evidence | Customer value | Expected? Will it recur? | Detection and stop option | Containment / blast radius | Next bounded action |
|---|---|---|---|---|---|---|---|
Customer action | What user event starts it, and how often? | Metrics slice, log sample, and app-specific rate | Which user outcome does it produce? | Normal demand; expected to continue? | Alert, rate limit, feature control, or none | What else stops or degrades? | Measure one optimisation or capacity decision |
Background job | Schedule, recursion, database event, or operator action | WU per run and total over the window | Required outcome, indirect value, or no clear value | Intended schedule; recurrence known? | Pause, cancel, recursion limit, or code change | One job, all scheduled jobs, or the whole app? | Test the narrowest safe control |
Anomalous activity | Observed source; keep unknowns explicit | Time-bounded spike and billing evidence | Usually none, but verify before deciding | Unexpected; recurrence remains possible? | Alert threshold and tested response | Cost, data, users, integrations, and availability affected | Add one guardrail, owner, and verification step |
The last three columns matter most. An expensive workflow with a clear owner, early alert, and narrow stop control is a different operational problem from an equally expensive workflow that can be contained only by affecting the whole product.
“Blast radius” should include more than availability. Ask what happens to customer transactions, scheduled jobs, third-party calls, queued work, and data consistency when the control is used. A kill switch that leaves half a business process running may be worse than it looks.
Follow the activity from trigger to bill
For each high-workload row, trace the same chain:
- Trigger: What caused the app to begin the work—a user action, scheduled API workflow, database change, external API request, retry, import, or operator action?
- Execution: Which page, workflow, action, expression, query, or integration performed the server-side work?
- Frequency: Did the activity cost a lot per execution, run too often, process too much data, or combine all three?
- Outcome: What changed for the customer or business when it completed?
- Recurrence: Is this ordinary demand, a known schedule, an error condition, or an event whose cause remains unresolved?
- Control: How will the team detect it, and what is the narrowest safe way to slow, pause, cancel, or isolate it?
- Verification: What evidence proves the intervention reduced consumption without breaking the intended outcome?
This keeps two common mistakes out of the analysis. First, a high-WU activity is not automatically waste; it may be the work customers are paying the product to do. Second, a low-cost action is not automatically harmless; repeated frequently enough, it can dominate a bill.
Name the kind of cost
At the end of the week, put each material activity into one of four working categories. These are operating judgments, not Bubble billing categories.
1. Valuable growth
Customers are using the product more, and the additional work produces a proportionate outcome. The response may be to accept the cost, change the plan or workload tier, improve unit economics, and continue monitoring.
The important number is not total WU alone. It is workload per useful unit: per completed booking, processed order, generated report, active account, or another product-specific outcome. Choose a denominator the business actually values.
2. Avoidable inefficiency
The activity is legitimate, but the implementation performs unnecessary work. Examples could include repeated searches, oversized data operations, redundant API calls, or background work running more frequently than the product requires. Bubble's optimisation material frames common causes as complexity, volume, and repetition, which is a useful starting point—not a prediction of savings in your app. (Bubble: optimisation framework)
Change one bounded mechanism and measure the same activity again. Do not declare victory because the total invoice fell during a quieter week.
3. Operational incident
The work was not intended to create customer value: an error, runaway process, unintended retry pattern, abusive request pattern, or another abnormal event caused consumption.
Do not invent the cause from the shape of a chart. Preserve the timeline, logs, trigger evidence, response actions, and uncertainty. Then test the detection and containment path. A post-incident optimisation that makes the normal path cheaper is not the same as preventing recurrence or limiting the next incident.
4. Platform-fit pressure
The app's valuable or necessary work is understood, but the team cannot achieve an acceptable combination of cost predictability, selective control, performance, or product capability within the current operating model.
That is stronger evidence for architectural change than an isolated large invoice. It still does not prove that a rewrite is economical. A replacement estimate must include migration, infrastructure, monitoring, security, backups, incident response, and continuing maintenance. Comparing Bubble with a small server leaves most of the replacement out.
Bubble has controls, but they are not all the same control
It would be inaccurate to say Bubble offers no protection.
Bubble provides automatic workload notifications and configurable thresholds. Its documentation says automatic alerts cover allowance milestones and workload spikes; custom alerts can use a WU threshold over an hour, day, week, or month. (Bubble: workload notifications)
For scheduled API workflows, the scheduler can show upcoming work, pause all scheduled API workflows, and cancel pending workflows. Bubble also documents cancellation of a specific scheduled workflow when its generated ID has been retained. (Bubble: API workflow scheduler, scheduling API workflows)
For recursive workflow chains, Infinite Recursion Protection can apply an app-level depth limit and terminate a chain that exceeds it. Bubble presents this as a backstop for recursive scheduling, not protection from every source of workload. (Bubble: Infinite Recursion Protection)
At the billing level, an owner can disable overages. Bubble says that if the app then exhausts the workload included in its plan and purchased tier, the app is taken offline until overages are enabled, more workload is purchased, or the next billing period starts. (Bubble: pricing and workload FAQ)
These controls operate at different scopes. An alert detects; it does not stop. A scheduler pause affects scheduled API workflows, not every possible activity, and Bubble warns that pausing tasks stops all API workflows in that environment. Recursion protection covers recursive chains. Disabling overages caps billable workload by coupling the cap to app availability.
The audit should therefore record which control applies to each costly activity and what else that control affects. “We have alerts” and “we can contain this failure safely” are different claims.
What to do on day eight
Choose one bounded response for each major category:
- Valuable growth: confirm the unit economics, capacity choice, and alert thresholds.
- Avoidable inefficiency: change one mechanism and compare the same activity before and after.
- Operational incident: add a prevention or containment guardrail, name the responder, and rehearse the stop-and-recovery path.
- Platform-fit pressure: define the specific control or capability the current platform cannot meet, then compare staying, partial replacement, and rebuilding against the same requirement.
Do not combine all four into “the platform is expensive.” That conclusion loses the mechanism and produces bad decisions. Growth may deserve more capacity. Waste deserves optimisation. An incident deserves a control review. A structural constraint may deserve migration discovery.
Then repeat the measurement. A seven-day audit is a diagnostic pass, not a permanent monitoring system. Keep the log structure, choose a more representative follow-up window, and compare like with like.
What this audit cannot tell you
Seven days cannot prove that an incident will not recur. It cannot reveal work that did not happen during the window. It cannot establish the full cost of a code replacement. It cannot decide how much availability risk the business should accept. And it cannot turn an uncorroborated founder observation into audited financial evidence.
It can give the next decision a mechanism.
Our $1,400+ incident is a reason to improve attribution, detection, containment, and recovery. It is not, by itself, proof that we should leave Bubble. The migration case becomes credible only if the evidence shows that valuable or necessary work remains too costly or insufficiently controllable after bounded improvements—and if the replacement plan accepts the responsibilities that Bubble currently bundles.
The invoice is evidence. The seven-day audit is how we begin to explain it.