Bubble Not Working? Fix the 10 Most Common Errors (2026)

Start Here: 90-Second Bubble Triage

Before you edit anything, separate the failure into four places: Bubble editor, Bubble preview, live app, and browser runtime. A fix that works in preview can still fail on live because live has separate database content, live API keys, live privacy behavior, and different deployed plugin versions. Open the deployed app in an incognito window with DevTools open, then check Console, Network filtered to Fetch/XHR, and Application storage.

In Console, red JavaScript errors usually point to plugin code, missing elements, broken custom code, or deleted references. In Network, a 400 often means request shape or missing fields, a 401 means authentication, a 403 usually means Cloudflare or a domain level block rather than anything inside your app, and a 500 usually means the external service or a server-side workflow failed. In Application storage, confirm cookies, local storage, and session state if login loops or subscription gates are involved.

If the app only breaks on live, compare the branch History tab and the server logs before changing workflows. If it breaks only for one user role, inspect privacy rules and option set conditions. If it breaks after a plugin update, revert or isolate that plugin on a blank test page. For broader rescue planning, AppStuck's Bubble support page explains how we approach inherited Bubble apps without guessing.

Three checks that cost sixty seconds and settle a blank page faster than anything else. Open status.bubble.io: if Bubble reports an incident, stop debugging and wait. Load the live app in an incognito window with extensions disabled, because ad blockers and privacy extensions block Bubble's own requests often enough to explain a real share of blank pages. And use Bubble's Safe mode, by pressing and holding the Preview button in the editor, to run the app with plugins, custom code or page workflows disabled: it isolates a blank page far faster than deleting elements by hand.

1. Blank or Stuck Page on the Live App

What it looks like: the Bubble preview may load, but the deployed app shows a blank page, an infinite loader, or a layout shell with no data. Users may also report that the page loads but nothing on it responds, which usually means the HTML rendered and a script failed afterwards.

Why it happens: most often, the live version is running different data, API keys, privacy rules, or plugin code than version-test. The second most common cause is a JavaScript error during page initialization, often from a plugin element, custom code block, or deleted element reference. Third, the page is waiting on a search or API call that never resolves.

Fix the blank live page:

1. Open the live URL in incognito and open DevTools before the page loads.
2. Check Console for errors such as ReferenceError, Cannot read properties of undefined, or plugin stack traces.
3. In Network, filter to Fetch/XHR and reload. Look for pending requests, 403 responses, or failed API calls.
4. Open Bubble Logs, then run the same page load in live mode and inspect server logs for failing server side actions or workflow failures.
5. Temporarily disable recently added plugin elements, custom HTML, and page-load workflows one at a time on a duplicate page.
6. If the issue started after deployment, compare against the previous savepoint in the branch History tab before making more changes.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"I have a Bubble live page that loads blank. Here is the Console error and the failed Fetch/XHR request: [paste error]. Tell me whether this points to plugin JavaScript, privacy rules, API initialization, or a page-load workflow."

A useful shortcut is to duplicate the broken page and remove half the page elements, then test. If the page loads, the problem is in the removed half. Repeat until the bad element, reusable element, or plugin is isolated. Do not debug visual layout first; blank pages are usually runtime failures, not responsive settings.

When to call an expert: call someone in when the live page fails only for certain roles, only after login, or only after a specific deployment. That usually means multiple systems are interacting and single-change debugging can make the live app worse.

2. Workflow That Does Not Run When Clicked

What it looks like: a user clicks a button, submits a form, or changes a dropdown, but nothing visible happens. Sometimes the first action runs and later actions do not. Sometimes the Bubble debugger shows the workflow starting, but the database does not update.

Why it happens: most often, a condition on the event or action is false. The second most common cause is a missing thing, empty input, or privacy rule that prevents the action from seeing the data it needs. Third, the workflow is failing silently because an earlier API, database, or navigation action stops the sequence.

The workflow error messages people actually paste, and what each one means:

• Workflows could not run because too many events triggered at the same time: an event is firing in a loop, usually a "Do when condition is true" set to "Every time" instead of "Just once".
• Cannot run workflow, relies on invalid inputs: the workflow references an input or dynamic value that is empty or of the wrong type at the moment it runs.
• A backend workflow that shows as successful in Logs while nothing changed: the run happened, but its search found nothing, usually because a privacy rule hides the data from the server side context.
• A scheduled workflow that never runs at all: check that the scheduled date is in the future at the moment of scheduling, and that a recursive workflow has a stop condition it can actually reach.
• An error occurred while running the workflow: this browser message is generic. Open Logs at that timestamp, because the real cause is server side.

Fix the workflow that does not run:

1. Run the page with ?debug_mode=true and use Step-by-step mode.
2. Click the element and confirm the event appears in the debugger. If it does not, inspect the element conditionals and visibility.
3. Check every Only when condition on the event and each action.
4. Inspect dynamic values inside the failing action. Look for empty current user, parent group's thing, or custom state.
5. Open Logs for the same timestamp and check whether a server-side action failed after the browser event started.
6. Move risky API and database actions earlier on a duplicate workflow to isolate the failing step.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"This Bubble workflow does not complete. Here are the event conditions, action list, and debugger output: [paste error]. Identify which action is being skipped or failing and what data is missing."

For a deeper workflow-specific walkthrough, use our guide to troubleshooting Bubble workflow errors. The short version is to prove the click fires, prove the conditions are true, then prove each action has the data and permissions it expects.

If a workflow is important to revenue, account creation, booking, or fulfillment, add a temporary diagnostic step that creates a small DebugLog thing with user, page, action name, and timestamp. Remove it after the fix. It is often faster than reading visual editor logic across nested conditions.

When to call an expert: get help when the workflow spans frontend actions, backend workflows, scheduled API workflows, and external services. At that point the bug is a transaction design problem, not just a broken button.

If you want a senior Bubble engineer to trace the workflow chain with you, book a Bubble rescue assessment before you rewrite working parts of the app.

3. API Connector 400 or Failed Call

What it looks like: Bubble's API Connector returns 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, a timeout, or a generic failed call message. The same request may work in a third-party API tool but fail inside Bubble.

Why it happens: most often, the request body or query parameters do not match the API's expected schema. The second most common cause is authentication placement, such as a bearer token in the wrong header or an expired live key. Third, Bubble has re-initialized the call with sample values that do not match live dynamic values.

Fix the API failed call:

1. Open Plugins, then API Connector, and identify whether the call is used as Data or Action.
2. Check method, URL, headers, body type, and whether values are marked private.
3. Re-initialize with realistic sample data. Take care with POST, PATCH and DELETE calls: Bubble warns that initializing a call runs it for real and can modify live data, so use non-destructive endpoints or disposable records when you initialize.
4. In live mode, inspect Network for the response body and compare it with the API Connector initialization response.
5. Confirm live keys are present under the correct environment and not only in version-test.
6. If the call is backend-only, inspect server logs instead of relying only on the browser console.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"Bubble API Connector returns [paste error]. Here are the method, URL, headers, body, and response body. Tell me whether the failure is schema, authentication, endpoint, CORS, privacy, or timeout related."

The full long-form fix is in our Bubble API Connector 400 and failed call guide. The key here is to stop editing random headers and instead compare four things: the initialized call, the runtime dynamic values, the live environment secrets, and the actual response body.

When to call an expert: escalate when the API touches payments, healthcare, identity, fulfillment, or signed webhooks. A quick fix can create a security hole if tokens, user IDs, or webhook secrets are handled in the browser.

4. Stripe Subscription Not Activating After Payment

What it looks like: Stripe shows a successful payment or subscription, but the Bubble user remains on a free plan, the dashboard stays locked, or the app asks the customer to subscribe again. Sometimes the issue happens only in live mode because test and live Stripe products are separate.

Why it happens: most often, the app treats checkout completion as proof of subscription instead of listening for the correct Stripe subscription event. The second most common cause is mismatched product, price, customer, or user mapping between Stripe and Bubble. Third, the webhook is installed but fails because the endpoint, signing secret, or backend workflow condition is wrong.

Fix the Stripe inactive subscription:

1. Confirm whether the app uses Bubble's Stripe plugin, Stripe Checkout through API Connector, or a third-party plugin.
2. In Stripe, compare test mode and live mode products, prices, webhook endpoints, and customer IDs.
3. In Bubble, check the user fields that store stripe_customer_id, subscription_id, plan, and status.
4. Inspect backend workflows that receive webhook events such as checkout.session.completed and customer.subscription.updated.
5. Check Bubble Logs at the webhook timestamp and verify the workflow found the correct user.
6. Never grant paid access only from a redirect page. Use the subscription status from Stripe or the verified webhook path.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"My Bubble app accepts a Stripe payment but does not activate the subscription. Here are the webhook event, Bubble backend workflow, and user fields: [paste error]. Find the missing mapping or failed condition."

Our dedicated Bubble Stripe subscription errors guide goes deeper into webhook setup and plan-state design. For this checklist, focus on one truth source. The paid state should be based on Stripe subscription status, not on the user reaching a success page.

When to call an expert: call an expert when customers have paid but access is wrong, duplicated, or missing. Subscription bugs affect trust quickly, and manual database edits can make refunds, renewals, and cancellations harder to reconcile later.

5. Data Not Showing: Repeating Groups Come Back Empty

What it looks like: data exists in App Data, but repeating groups show empty, detail pages show blank fields, searches return fewer rows than expected, or an API workflow cannot find a thing. Privacy rules do not produce a visible error: Bubble simply does not send the data to the browser, so the UI looks empty and the Network tab looks clean. That silence is the symptom.

Why it happens: most often, no privacy rule grants the current user permission to view the thing or one of its fields. Privacy rules are additive and they grant access rather than block it, so the cause is a missing permission, not a rule that is stopping you. The second most common cause is a search constraint that depends on a field hidden by privacy. Third, the app has different data ownership rules in live than in development, especially after imports or manual database edits.

Fix the blocked database read:

1. Go to Data, then Privacy, and choose the affected data type.
2. Read the rules as permissions that stack: a user gets the sum of every rule they match. If nothing matches, they see nothing. Look for the grant that is missing, not for a rule that blocks.
3. Confirm the role allows the fields your page or workflow needs, not just the thing itself.
4. Temporarily display Current User's unique id and the thing owner's unique id on a hidden admin-only diagnostic page.
5. Run the search as the affected user, not as an admin account.
6. Check live App Data to confirm ownership fields are populated correctly.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"Bubble shows no data even though the database has records. Here are the privacy rules, search constraints, current user role, and data type fields: [paste your privacy rules and the search]. Identify which rule blocks the read."

Privacy rules are not just security settings. They also shape what the client can see and what searches can return. A repeating group that works for the admin but not for a normal user is almost never a layout problem. It is usually an ownership, role, or field visibility problem.

Use the Bubble rescue hub if your app has grown into many roles, teams, organizations, or account types. Complex privacy design needs a model, not a pile of exceptions.

When to call an expert: escalate when the quick fix is to make fields public or loosen every role. That may make the page work, but it can expose customer, financial, or internal data to the wrong users.

6. Deployment to Live Failing or Live Version Looks Wrong

What it looks like: Bubble refuses to deploy, deployment completes but live still looks old, the live app has missing workflows, or a fix works in version-test but not on the public domain. Sometimes the issue appears after a plugin update, custom domain change, or database schema change.

Why it happens: most often, the app has unresolved issues that block deployment or a deployment was made from the wrong branch of changes. The second most common cause is environment drift, where live keys, live data, and live plugin settings differ from development. Third, the browser or CDN is serving cached assets after a deployment.

Fix the deployment failure:

1. Open the Issue Checker and resolve blocking issues first, especially deleted elements, missing fields, and invalid dynamic expressions.
2. Open the History tab for the branch and confirm the latest deployment includes the expected changes, then check Logs, then Server logs at that timestamp.
3. Deploy a tiny visible text change on a test page to prove whether deployment is actually reaching live.
4. Check Settings, then Domain and email, if the issue appears only on the custom domain.
5. Compare live API keys, plugin settings, and database values against development.
6. Hard refresh in incognito and test the Bubble app URL as well as the custom domain.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"My Bubble deployment fails or live does not match development. Here are the deployment error, issue checker output, and affected page: [paste error]. Tell me what blocks live release."

For deployment-specific detail, see our Bubble app deployment errors guide. The main habit is to avoid mixing deployment debugging with feature work. Freeze changes, identify the exact deployed version, then test the smallest possible live change.

When to call an expert: call for help when production users are active and you cannot confidently roll forward or roll back. Live release debugging should preserve data and user sessions, not just get the editor to turn green.

7. App Slow as Data Grows

What it looks like: the app felt fine with sample data, then pages became slow after imports, paying users, or larger repeating groups. Searches take longer, workflows time out, and users on slower connections see inputs lag behind their typing because the page is doing too much work.

Why it happens: most often, pages load too much data into the browser. The second most common cause is unbounded searches inside repeating groups or nested groups. Third, workflows do repeated database writes, scheduled workflows, or API calls without batching or filtering.

Fix the slow Bubble app:

1. Open the slow page in incognito with Network open and watch how many requests fire on load.
2. Inspect repeating groups for Do a search for with weak constraints or no pagination.
3. Move expensive calculations from the page into saved fields, backend workflows, or scheduled jobs where appropriate.
4. Remove hidden groups that still evaluate heavy dynamic expressions.
5. Use search constraints before advanced filters. Advanced filters usually run after more data has already been loaded.
6. Test as a normal user with realistic live data, not with an admin account and small development data.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"This Bubble page slows down as data grows. Here are the repeating group data sources, searches, filters, and page-load workflows: [paste the data source and constraints]. Identify the expensive searches and safer replacements."

Our Bubble performance optimization guide covers this in more depth. In a broken app, start with the first screenful: page-load workflows, visible repeating groups, reusable elements, and conditionals. Those are the parts users pay for every time they land on the page.

Performance work is also product work. If the app needs reporting across large datasets, consider separate admin reports, precomputed totals, or external data architecture rather than forcing every user page to do analytics in real time.

When to call an expert: escalate when performance problems are tied to the data model itself. If every page depends on broad searches across loosely related things, small UI tweaks will not fix the underlying architecture.

8. App Breaks After a Plugin Update

What it looks like: a page, workflow, payment form, map, chart, or mobile interaction breaks after updating a Bubble plugin or installing a new one. Console errors may mention minified JavaScript, undefined functions, missing assets, or a plugin element. The editor may also start freezing or crashing more often.

Why it happens: most often, the plugin changed its JavaScript, exposed states, action names, or initialization timing. The second most common cause is a conflict between two plugins loading similar libraries. Third, the plugin works in preview but fails on live because plugin settings or API keys differ by environment.

Fix the plugin conflict:

1. Open Plugins and write down the plugin name, current version, and recent update time.
2. Duplicate the affected page and remove the plugin element. If the page works, the plugin is implicated.
3. Disable workflows that call plugin actions, then re-enable them one at a time.
4. Check Console for the plugin name, exposed state, or JavaScript function near the first red error.
5. Review plugin settings for development and live keys, especially for maps, payments, auth, and file handling.
6. If Bubble allows it for that plugin, revert to the prior version or replace the plugin with native Bubble functionality on the critical path.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"A Bubble plugin update broke this page. Here are the console error, plugin name, workflows using plugin actions, and whether it fails in live or preview: [paste error]. Identify the isolation steps."

Plugin problems are frustrating because the failure may sit outside your app logic. Still, you can isolate them cleanly. Build a blank test page with only the plugin element and minimum data needed. If it fails there, stop refactoring the real page and decide whether to revert, replace, or contact the plugin owner.

When to call an expert: call an expert when a plugin controls authentication, payments, native mobile behavior, file uploads, or core data writes. Replacing it may require workflow redesign, data cleanup, and a safer release plan.

9. Reference Error After Deleting an Element

What it looks like: the browser console shows ReferenceError, Cannot read properties of undefined, or a missing element-like error after you deleted, renamed, or moved an element. Bubble's issue checker may not point clearly to the broken path, and the page may fail only when a specific workflow runs.

Why it happens: most often, a workflow, conditional, custom state, reusable element, plugin action, or dynamic expression still points at an element that no longer exists or no longer has the expected type. The second most common cause is custom JavaScript referencing an old element ID. Third, reusable element boundaries changed and the expression lost access to the expected parent data.

Fix the reference error:

1. Copy the exact console error and note the user action that triggers it.
2. Open Issue Checker and filter for page-level issues, missing elements, and invalid dynamic expressions.
3. Search the page workflows for references to the deleted element name, old custom state, or parent group data.
4. Inspect conditionals on hidden elements. They can still evaluate broken expressions even when not visible.
5. Check reusable elements and plugin actions that used the deleted element as a target.
6. Restore the element temporarily on a duplicate page if needed, then replace references deliberately before deleting it again.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"Bubble throws this reference error after an element was deleted: [paste error]. Here are the related workflows, conditionals, and custom states. Find likely stale references."

The full walkthrough is in our guide to fixing Bubble reference errors fast. The practical summary is to search beyond visible workflows. Broken references hide in conditionals, reusable elements, plugin action settings, custom states, and expressions that Bubble evaluates on page load.

If you are considering leaving Bubble because repeated reference and plugin issues make the app feel trapped, read our plain-English overview of what Bubble code export really gives you. Export is not a magic rescue path, but it can clarify whether rebuilding outside Bubble is more realistic than continuing to patch.

When to call an expert: escalate when reference errors spread across reusable elements and core workflows. That usually means the app needs a controlled refactor, not another delete-and-recreate attempt.

10. Workflows Stop Halfway: Workload Unit Limits

What it looks like: Bubble emails you when the app reaches 75 percent of its monthly workload allowance. Past the allowance the behaviour depends on one setting: with overages enabled the app keeps running and the extra usage is billed, and with overages disabled the app is taken offline. Workload does not throttle your app: Bubble states that there is no direct relationship between workload and speed. If the app feels slow, that is the data model, not the workload meter, and it belongs in the section above. The old capacity metric that did throttle apps was retired in April 2023. Admin pages and bulk actions are usually the first to suffer.

Why it happens: most often, the app performs too many expensive searches, writes, or API actions for each user action. The second most common cause is recursive or scheduled backend workflows that process one thing at a time without batching strategy. Third, page design triggers repeated searches whenever inputs, filters, or custom states change.

Fix the WU limit problem:

1. Open Bubble's workload and logs views and identify which pages or workflows consume the most work.
2. Look for repeating group searches that run on every page load, filter change, or conditional evaluation.
3. Replace repeated calculations with stored fields when the value does not need to be real time.
4. Batch backend work in predictable chunks and avoid scheduling one workflow per thing without a stop condition.
5. Remove duplicate writes where multiple actions update the same thing in sequence.
6. Separate admin analytics, exports, and bulk operations from normal user flows.

Prompt to paste into ChatGPT, Claude or the Bubble AI assistant:

"My Bubble app is hitting workload limits. Here are the heaviest workflows, searches, repeating groups, and scheduled jobs: [paste the workload unit breakdown]. Rank the likely WU drains and suggest safer architecture."

WU problems are not only a plan-size issue. Upgrading can buy time, but it will not fix a workflow that writes repeatedly, searches broadly, or schedules thousands of tiny jobs. Start by finding the action that scales with users or records, then reduce how often it runs and how much data it touches.

This is where Bubble architecture help pays off. A well-structured Bubble app can keep high-cost work away from normal page loads and reserve backend processing for jobs that actually need it.

When to call an expert: call an expert when workload limits affect core revenue flows, signups, payments, bookings, or imports. The safe fix may require redesigning data access patterns and backend queues while the app remains live.

Bubble not working: quick answers

Is my Bubble app broken, or is Bubble down?

Check status.bubble.io first, then open the app in an incognito window on a different network, such as a phone on mobile data. If it fails everywhere and Bubble reports an incident, wait instead of debugging. If Bubble reports nothing and the app works in incognito but not in your normal browser, the cause is a browser extension, an ad blocker or a cached asset, not your app.

Why does my Bubble app work in preview but not on live?

Live and preview are separate environments with different database content, different API keys and different deployed plugin versions, and privacy rules evaluate against different data. Deploy a one word visible text change to prove the deployment is reaching live at all, then open the live URL in incognito with DevTools open and compare the Console and the Fetch/XHR responses against preview. Data that appears in preview and is missing on live is almost always a privacy rule evaluated against live data. Privacy rules do not return an error: the data is simply not sent, so the page looks empty rather than broken.

Why is my Bubble workflow not running when I click the button?

Run the page with ?debug_mode=true in Step-by-step mode and confirm the event fires at all. If the event never appears, the problem is the element, its visibility or a conditional, not the workflow. If the event fires but actions are skipped, an Only when condition is false or a dynamic value it needs is empty. If the debugger looks clean and the database still does not change, the failure is server side and you need the Logs at that timestamp, not the browser console.

Why does my backend workflow say it succeeded but nothing happened?

A backend workflow logs as successful when it ran, not when it did what you expected. The usual causes are a privacy rule hiding the data from the server side context so the search finds nothing, a parameter arriving empty from the caller, or an Only when condition that is false at server time. Open Logs, expand the run and check the parameter values that actually arrived rather than the ones you think you sent.

When should I stop debugging and get help?

When the fix requires loosening security, when the failure crosses systems, or when live users are affected by every attempt. Making privacy rules public so the data appears is not a fix, it is an exposure. And if performance degrades as data grows, the cause is the data model rather than the page, so more patches will not help.

When Self-Debugging Stops Making Sense

Most Bubble not working common errors above are fixable if you isolate the layer, read the actual error, and change one thing at a time.

• The error crosses systems: a workflow touches Bubble data, API Connector, Stripe, privacy rules, and backend workflows in one path.
• Live users are affected: every debugging change risks customer data, paid access, bookings, or onboarding.
• You are loosening security to make data appear: changing privacy rules to public is a warning sign, not a fix.
• The app only fails in production: live-only bugs need environment, data, and deployment diagnosis, not preview-only testing.
• Performance gets worse as you grow: that usually means data model and search architecture issues, not just page speed polish.
• You are considering a rebuild: before abandoning Bubble, get a technical read on what can be rescued, what should be rebuilt, and what should stay as-is.

AppStuck specializes in rescuing and completing Bubble projects. AppStuck takes on Bubble rescue and completion projects, and we will tell you honestly what your project needs and what it costs before any work starts.