Bubble: recursive workflow stops after one failed run
A recursive workflow starts correctly, works through part of the list, then stops for good. The scheduler is empty, no error is surfaced anywhere a user would see, and the remaining records are simply never processed.
- Bubble
- Scheduled jobs
Root cause, in plain English
A recursive workflow keeps itself alive by scheduling its own next run as one of its final steps. That makes the chain exactly as durable as its weakest run: if any single execution errors before reaching the scheduling step, nothing schedules the successor and the whole chain ends silently. There is no retry and no supervisor, because the workflow was the only thing keeping itself going.
How to fix it
Open Logs, then the Scheduler, and confirm nothing is queued. An empty scheduler alongside a half-processed list is the signature of a broken chain rather than a slow one.
Read the server logs around the last successful run to find the record that errored. Bad or missing data on one row is the usual trigger.
Schedule the next run early in the workflow rather than at the end, so a failure while processing a record cannot prevent the chain continuing.
Guard the per-record work so one bad row cannot abort the run: check for the fields you depend on and skip rather than error when they are absent.
Give the chain an explicit stop condition and a heartbeat, so both a finished run and a stalled one are distinguishable from outside.
How Nightlamp detects this automatically
- Heartbeat
- API canary
A heartbeat check is the right shape for this failure: the workflow pings Nightlamp at the end of each run, and Nightlamp alerts when an expected ping does not arrive. That inverts the problem — instead of needing the broken chain to report its own failure, silence itself becomes the alert. An api_canary on an endpoint that exposes queue depth catches a backlog building up behind a stalled chain.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- Why is there no error anywhere?
- The error is in the server logs for that one run, but nothing escalates it. The chain does not fail loudly — it simply stops existing, and an absence of scheduled work looks identical to work that finished normally.
- Will Bubble retry the failed run automatically?
- No. A scheduled run that errors is done, and because scheduling the successor was a step inside it, the chain ends with it. Any retry behaviour has to be something you build.
- Is scheduling the next run first actually safe?
- It changes the failure mode from stopping silently to potentially continuing past a bad record, which is usually what you want for a backlog. Pair it with a clear termination condition so a scheduling loop cannot run away when the list is exhausted.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.