Make.com 'Bundle is Empty' Error: How to Fix Failing Scenarios

April 29, 2026 · Editorial Team · 6 min read · make-com troubleshooting error-fix

You're a marketing automator who built a Make.com scenario that polls a Google Sheets document every 15 minutes, runs new rows through an OpenAI module to generate personalized cold email copy, and sends the result via Gmail. It ran perfectly for two weeks. Then you open Make's operations log and see a wall of red: The operation failed with an error. Bundle is empty. There is no bundle to transfer. Every run after 11 PM last Tuesday has failed. The scenario structure looks fine. Nothing changed. This guide walks through exactly what's causing it and how to stop it from coming back.

What this error actually means

In Make.com's data model, a "bundle" is a single unit of data passing through a scenario, basically one row, one record, or one API response. When Make says "bundle is empty," it means a module in your scenario received zero bundles from the upstream module. The downstream module was configured expecting at least one bundle, and with none arriving, it had nothing to act on and threw this error.

The error itself is not a connection failure or an API problem. It's Make's way of saying "the previous step returned nothing, and I don't know what to do with that." Depending on your scenario's error-handling settings, this can trip the error handler and stop the entire scenario run, or it can silently skip the module and cause downstream data gaps you don't notice until you audit outputs.

Quick fix (when you need it working in 60 seconds)

Open the failing scenario run in Make's execution history (Scenarios > History). Click the failed run and look at the module where the bundle count drops to zero.
Click that module to see its output panel. If it shows [] or No records, the issue is that the data source returned nothing for that run.
Add a Router module after the problematic source module. On the main route, add a Filter set to Number of bundles > 0. This stops the scenario gracefully when there's no data rather than erroring.
Enable "Ignore Incomplete Executions" in the scenario settings (the wrench icon, then "Settings") to prevent the scenario from marking itself as failed when it encounters an empty bundle.
Re-run the scenario manually using the "Run Once" button to confirm it completes cleanly with the filter in place.

Why this happens

The most common root cause is a polling module that triggers on schedule but finds no new data. Your Google Sheets "Watch Rows" module is configured to watch for new rows added since the last run. At 11 PM on Tuesday, no new rows were added, so the module returned zero bundles. With no filter in place, the OpenAI module downstream received nothing and threw the error. This is actually expected behavior from Make's perspective, but the default error handling treats zero bundles as a failure.

Another common cause is an API or data source returning an empty response due to filtering. If you added a filter to your Google Sheets module (for example, "only process rows where column D says 'Ready'"), and none of the rows in the latest batch meet that condition, the result is an empty bundle set. Make's bundle error makes it look like something broke when really your filter is working exactly as designed.

Rate limiting on upstream sources is a sneakier cause. If your Make scenario runs frequently and the upstream API rate-limits it, some runs will receive an HTTP 429 response, which Make's module might translate as an empty result bundle rather than a clean error, depending on how that module handles rate limit responses.

Finally, token or credential expiration can cause this. A Google Sheets connection token that expired will cause the Watch Rows module to fail silently in some Make versions rather than throwing an obvious auth error. The result looks like an empty bundle.

Permanent fix

Add a filter immediately after every trigger or source module. The filter condition should be Bundles: Total number of bundles > 0. This is Make's built-in way to gracefully handle empty data runs.
Set the scenario's error handling to "Resume" rather than "Rollback" for incomplete execution handling. Go to Scenario Settings > Error handling, and select "Resume next cycle" so the scenario continues its schedule even after a no-data run.
Change your trigger module from "Watch Rows" (event-based) to "Search Rows" if your workflow doesn't depend on detecting new rows specifically. "Search Rows" with explicit filter criteria gives you more control over what qualifies as a processable record.
Add a dedicated error handling route. Click the module where you most often see the empty bundle error, then click the small dot on its edge to add a route. On the error route, add a "Tools: Set Variable" module that logs the failure to a Google Sheet or sends a Slack notification with the run timestamp and error context.
Check your connections. Go to Organization > Connections and look for any connection with an "Expired" or "Needs reauthorization" badge. Reconnect them and retest.
If you're hitting Google Sheets API rate limits, reduce the scenario's scheduling frequency from every 15 minutes to every 30 minutes. Alternatively, switch from polling to a Google Sheets webhook trigger (available via a Pub/Sub integration), which eliminates polling entirely.
For OpenAI or Anthropic modules specifically, add a text length filter before the AI module. If the incoming text field is empty or under 10 characters, skip the AI step. This prevents the model API from receiving malformed requests that can also produce empty-looking results.
Enable Make's "Auto-commit" setting on data store operations if you're writing results to a Make Data Store. Without auto-commit, failed bundles can lock rows in the data store, causing subsequent runs to find those rows already "claimed" and returning nothing.

Prevention

Don't build scenarios that assume every run will have data. The polling model means some runs will always be empty. Design your scenario structure to treat "no new data" as a normal state, not an error. Filters and conditional routes are the right tool for this.

Review your scenario's execution history weekly. Make's history panel shows the bundle count per module per run. If you see the bundle count drop to zero at the same module consistently, that module's configuration needs adjustment. Regular audits catch these patterns before they cause a production failure.

Test your scenarios with both a "data present" case and a "no data" case before activating them. Make's "Run Once" lets you trigger a manual run. Test it right after clearing your test sheet (to simulate an empty data run) and confirm the scenario exits cleanly without errors.

When the fix doesn't work

If you've added filters and the error persists, check whether the module throwing the error is a built-in Make module or a third-party app module. Third-party modules sometimes have their own bundle validation logic that doesn't respect Make's native filter settings. In this case, contact the module developer or switch to Make's HTTP module to call the same API directly, which gives you full control over how empty responses are handled.

If you're on Make's Free or Core plan, some advanced error handling features are only available on higher tiers. Check the Make pricing page to confirm whether "Incomplete Executions" handling is available on your plan. Upgrading to the Pro plan enables the full error routing and logging capabilities that make managing empty bundles much easier.

For persistent issues that don't fit these patterns, post in the Make Community forum at community.make.com. Include your scenario structure (a screenshot with module names visible), the exact error message text, and the module where the bundle count drops. The community is active and usually responds within hours.