Why does my Bubble workflow run in version-test but not live?

Bubble's Development and Live environments exist in parallel with two independent databases. Changes made in Development — including new or edited workflows — do not affect Live until you deploy. Deploy the app, and remember data created while testing stays in the Development database; use Bubble's copy-and-restore database tools if Live needs it.

Why does a Bubble workflow skip without any error?

'Only when' conditions fail silently by design: if a workflow's condition evaluates to no, every action in it is skipped; if an action's condition fails, Bubble skips that action and moves on. No error is raised. The server logs have an advanced filter called Non-passed events that shows exactly which workflows didn't run because their condition evaluated to no.

Why does 'Do a search for' return nothing for real users?

Privacy rules. If a user's role lacks the 'Find this in searches' permission for a data type, searches exclude those records — and per Bubble's manual, if a workflow searches for a Thing the current user can't access, the result turns up empty, which can break the workflow downstream. Review the data type's privacy rules and test as a real user.

Are backend workflows available on Bubble's Free plan?

No. Bubble's pricing lists backend workflows starting on the Starter plan. Recurring events are also limited per plan — per Bubble's manual, one recurring event per thing on Starter, five on Growth, twenty on Team.

What happens when my Bubble app runs out of workload units?

The current workload model does not throttle (that was the legacy capacity system). On paid plans, exceeding included workload units triggers overage charges, with an email warning at 75% of available WU. If overages are disabled — or the app is on the Free plan, which can't enable them — the app is taken offline once units run out, until overages are enabled, a tier is purchased, or the next billing period starts.

Why did my scheduled API workflow never fire?

Check the scheduler in the editor's Logs tab: it lists queued scheduled workflows with their scheduled time, ID, and parameters, and has a pause toggle. Two classic catches: the Live and Development environments keep separate schedules, so a workflow scheduled in dev never runs in live — and external triggers fail if the workflow's authentication settings don't allow the caller.

Bubble diagnostics

Your Bubble workflow isn't running. Why won't Bubble tell you?

A Bubble workflow that "doesn't run" usually never triggered at all — and Bubble won't raise an error. The usual suspects: the change was never deployed to live, an "Only when" condition quietly evaluated to no, privacy rules emptied the search feeding it, the backend workflow isn't on your plan, or the app went offline on workload-unit overage. Start with the server logs' Non-passed events filter, then work the checks.

Start 14-day trial Jump to the checks

why it happens

Bubble fails quiet, not loud

Most platforms fail with a stack trace. Bubble fails by doing nothing: a condition evaluates to no and the run is skipped, a privacy rule empties a search, a change waits undeployed in the development environment. That's not a flaw — it's the contract. It just means diagnosis is about finding which silent gate closed, and the Logs tab (server logs, the Non-passed events filter, and the scheduler) is where every answer on this page lives.

the checklist

Seven silent gates — symptom, then fix

The change was never deployed to live

Symptom: The workflow runs perfectly in version-test; nothing happens on the real site.

Fix: Development and Live are parallel environments with two independent databases. Workflows you build or fix in Development do not exist in Live until you deploy. Deploy, then re-test on the live URL — and remember test data stays in the dev database.

An "Only when" condition is silently false

Symptom: The workflow exists in live, the trigger happens, and… nothing. No error anywhere.

Fix: Documented behavior: a false condition on a workflow prevents all its actions; a false condition on an action makes Bubble skip it and continue. Open Logs → server logs and switch on the Non-passed events advanced filter — it lists workflows that didn't run because the condition evaluated to no, which turns guessing into reading.

Privacy rules emptied the search feeding the workflow

Symptom: Works when you test as yourself; for real users the search finds nothing, so the workflow does nothing.

Fix: If the current user's role lacks "Find this in searches" on the data type, searches exclude those records — and Bubble's manual is explicit that a workflow searching for a Thing the user can't access turns up empty. Fix the privacy rule (or restructure so a backend workflow with proper authority does the search), then verify as a normal user account.

The backend workflow isn't available on your plan

Symptom: Schedule API Workflow is missing or the backend editor is locked.

Fix: Backend workflows start on the Starter plan — they're not on Free. Recurring events are limited per plan: per Bubble's manual, one per thing on Starter, five on Growth, twenty on Team. If the feature is plan-gated, no amount of debugging will make it fire.

The app went offline on workload-unit overage

Symptom: Everything stopped at once — pages and workflows — often near end of month.

Fix: The current WU model doesn't throttle. Paid plans with overages enabled pay per extra unit (warning email at 75%). With overages disabled — or on Free, which can't enable them — the app is taken offline when units run out. Re-enable overages or buy a tier, then find the WU-hungry workflow before next month repeats this.

The API workflow rejects external callers

Symptom: Stripe, Zapier, or your own service gets an authentication error calling the workflow.

Fix: API workflows carry authentication settings (the manual documents both the public-exposure checkbox and an authentication dropdown — set to None required for unauthenticated callers, or send a valid API token). Note the asymmetry: internally scheduled workflows ignore these settings; only external triggers hit them. Re-test with the provider's own delivery log open.

The schedule itself is wrong — or paused, or in the other environment

Symptom: A recurring or scheduled workflow simply never appears to run.

Fix: Open Logs → scheduler: queued workflows are listed with scheduled time (shown in your browser's timezone), ID, and parameters, and there's a pause toggle. The classic trap: Live and Development keep separate schedules — a recurring event started in dev does not exist in live. Re-schedule in the live environment and confirm it appears in the live scheduler.

copyable runbook

Paste this into your incident notes

Bubble workflow triage

[ ] Testing on the LIVE URL (not /version-test)? Was the change deployed?
[ ] Logs -> server logs -> advanced filter: Non-passed events. Is the workflow
    listed with its condition evaluating to no?
[ ] Privacy rules: does the current user's role have "Find this in searches"
    on every data type the workflow searches? Test as a real user.
[ ] Plan check: backend workflows need Starter+; recurring events are
    plan-limited (1 / 5 / 20 per thing on Starter / Growth / Team).
[ ] WU: overages enabled? 75% warning email in the inbox? App taken offline?
[ ] External trigger: authentication settings allow the caller (or token sent)?
    Provider's delivery log shows the request arriving?
[ ] Logs -> scheduler: workflow queued in the LIVE environment? Pause toggle off?
[ ] Errors filter in server logs: send-email / payment / API action failures.

how to catch it automatically

How Nightlamp catches this before your users do

Silent failures need checks that assert outcomes, not status codes. A heartbeat check is the cleanest: have the recurring or scheduled workflow's last action call a Nightlamp ping URL — if the workflow stops running for any of the reasons above, the missed heartbeat tells you the same day, not at month-end. An api_canary against your Workflow API or Data API proves external triggering and authentication still work, and that searches return data for a real (non-admin) account — the privacy-rule failure in miniature. A browser_journey runs the user-facing flow the workflow powers, end to end, on the live URL.

heartbeat — recurring/scheduled workflow pings after each run

api_canary — workflow API triggerable; search returns rows

browser_journey — the user flow the workflow powers

http_keyword — live URL serves live (no version-test)

http_status — app online (WU overage shows up here)

email_flow — workflow-sent email actually arrives

faq

Bubble workflow FAQ

Why does my workflow run in version-test but not live?

Development and Live are parallel environments with separate databases. Deploy the change — until then, Live runs the old version.

Why does a workflow skip with no error?

'Only when' conditions fail silently by design. The server logs' Non-passed events filter lists workflows that didn't run because the condition evaluated to no.

Why do searches return nothing for real users?

Privacy rules: without 'Find this in searches', records are excluded and workflow searches turn up empty. Fix the rule and test as a normal user.

Are backend workflows on the Free plan?

No — they start on Starter. Recurring events are plan-limited too: one per thing on Starter, five on Growth, twenty on Team.

Can running out of workload units stop my workflows?

Yes — but by going offline, not throttling. With overages disabled (or on Free), the app is taken offline when WU run out. Bubble emails a warning at 75%.

Want silent skips caught the same day?

Wire your critical workflows to a heartbeat, point a canary at your API, and let Nightlamp run the user flow nightly. When a condition flips or a deploy forgets the backend, you'll know before the month-end report is empty.

Start 14-day trial · no card

Newsletter

One real no-code incident + the fix, monthly

A post-mortem from a real no-code outage — what broke, how it was found, and the fix — once a month. Confirming also gets you the no-code incident runbook pack.

Double opt-in. One-click unsubscribe. No spam, ever.