Make.com Scenario Not Running? Troubleshooting Guide

TroubleshootingBy Muhammad Bilal AlviUpdated September 21, 202610 min read

You built a scenario in Make, tested it with Run once, and it worked. Now new orders or form entries are coming in, but nothing happens. Or the scenario ran for weeks and then went quiet, and the toggle that used to be on is now off.

The scenario may have been deactivated, the schedule may not match what you expect, a webhook may be rejecting requests, credits may be exhausted, or a filter or error handler may be quietly dropping bundles. The scenario’s history and settings show which.

Quick diagnostic checklist

Is the scenario’s scheduling switched on, or was it deactivated?
Does the History tab show recent runs, and with what status: success, warning, or error?
Does the scenario start with an instant trigger (webhook) or a scheduled trigger, and what is the schedule set to?
Does your organization have credits left for this billing period?
Do the connections used by the scenario verify successfully?
Are there items waiting in the Incomplete executions tab?
Is a filter between modules blocking the bundles you expect?
Has the incoming data format changed since the scenario was built?

Common causes of a Make scenario not running

1. The scenario was deactivated after errors

Make disables a scenario’s scheduling when it finishes with errors a set number of times in a row. The threshold is controlled by the Errors before deactivation option in scenario settings (older tutorials may call it the number of consecutive errors). There is an important exception: Make’s documentation states that if a scenario starts with an instant trigger, this setting is ignored and the scenario is deactivated as soon as the first error occurs.

2. A fatal error deactivated it immediately

Some errors stop scheduling regardless of the threshold. Make’s errors and warnings reference lists OperationsLimitExceededError (your credits are exhausted), DataSizeLimitExceededError (data transfer quota exhausted), and InconsistencyError (a rollback failed).

3. The schedule is not what you think

Scheduled scenarios run on the pattern set in schedule settings: at regular intervals (every 15 minutes by default), once a day, on weekdays, weekly, monthly, on specified dates, or On demand. A scenario set to On demand only runs when someone starts it manually. Under Show advanced settings you can also set start and end dates; if the end date has passed, the scenario stops being scheduled. Minimum intervals depend on your plan.

4. Webhook requests are rejected or queued

Instant scenarios start from a webhook. Per Make’s webhooks documentation, a webhook accepts up to 300 requests per 10 seconds and returns HTTP 429 beyond that. Each webhook has a queue sized by your licensed credits (up to 10,000 items); when the queue is full, new requests get a 400 response. If a webhook uses a data structure for validation, requests that do not match are rejected with a 400. Webhooks not connected to any scenario are deactivated after 5 days.

5. A connection needs reauthorization

Many apps use OAuth 2.0, which grants access for a limited time. Make’s connection guide notes that such connections may need periodic reauthorization, and that reauthorization fails when the browser blocks the pop-up, tokens are revoked, or permissions change. Authentication failures surface as AccountValidationError, one of the error types that counts toward deactivation.

6. Incomplete executions are blocking new runs

With Store incomplete executions enabled, a failed run is saved so you can resolve it later. Combined with Process data in order, Make waits for earlier runs to finish before starting the next. An unresolved incomplete execution can hold up everything behind it.

7. A filter or error handler is dropping bundles

Filters sit on the links between modules and stop any bundle that does not meet the condition. Error handlers can have the same effect: the Skip handler removes the failing bundle and lets the run finish with a success status.

8. The incoming data changed shape

When a form adds a question, an e-commerce platform changes its payload, or a sheet gains a column, mapped fields may come through empty or fail validation with a BundleValidationError. For custom webhooks, the webhook’s settings let you detect new values by sending a fresh sample request, as described in the Webhooks app documentation.

Step-by-step troubleshooting

Check the scenario status and the change log. Open the scenario and look at the scheduling switch. Then open the History tab. Scenario history records changes such as scheduling and activation alongside runs, so you can see whether the scenario was deactivated by the system or switched off by a person, and when.
Open the last runs before it stopped. Click Details on the most recent error or warning runs. Look at which module failed, the error type, and the output bundles of the modules before it.
Check credits before anything else if several scenarios stopped together. Look at your organization’s credit usage for the current period. If credits are exhausted, fixing individual scenarios will not help. Make’s credits page describes buying extra credits or enabling automatic extra credit purchases.
Verify each connection. Go to Credentials in the left sidebar and open the Connections tab. Use Verify on each connection the scenario uses. If verification fails, use Reauthorize, signing in as a user with the same permissions as before.
Review the schedule. Open schedule settings and confirm the run pattern, the interval, and any advanced start or end dates. For instant triggers, the schedule should show that it runs immediately as data arrives.
Test the webhook directly. Send a controlled test request with fake data (see the example below) and watch whether it appears in the webhook queue and whether the scenario picks it up. A 200 response means Make accepted it; a 400 or 429 points to validation, a full queue, or rate limiting.
Inspect filters on the path the record should take. Run the scenario once with a test record and look at the numbers shown on each module after the run. If a module after a filter received zero bundles, compare the filter condition to the actual values in the preceding module’s output.
Resolve incomplete executions. Open the Incomplete executions tab. Fix the cause, then retry them, or delete ones that should not be processed. Retrying an order that was already partly written to another system can create duplicates, so check the destination first.
Reactivate and watch the next real run. Turn scheduling back on only after you have fixed the cause. Then confirm the next live run in History.

Testing a Make webhook safely

This Node.js 18+ snippet sends one fake order to a custom webhook so you can see how Make responds. Replace the placeholder with your webhook URL, and point it at a test scenario or a copy rather than a production one.

// Send one test payload to a Make custom webhook (Node.js 18+).
const WEBHOOK_URL = "YOUR_MAKE_WEBHOOK_URL"; // keep real URLs out of shared code

const testOrder = {
  order_id: "TEST-1001",
  email: "test.customer@example.com",
  total: 49.0,
  currency: "USD",
  created_at: new Date().toISOString()
};

const res = await fetch(WEBHOOK_URL, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(testOrder)
});

console.log(res.status, await res.text());
// 200 = accepted into the queue; 400 = queue full or failed validation; 429 = rate limited

Make error handlers and what they do to your data

Make currently documents five error handlers. Choosing the wrong one is a common reason a scenario “runs” without doing its job, or stops when it should have continued.

Handler	Behavior	Run status
Skip	Removes the failing bundle and continues with the next one.	Success
Retry	Pulls the failing bundle out and stores it as an incomplete execution; can retry automatically at a set interval and number of attempts. Requires incomplete executions to be enabled.	Warning
Resume	Substitutes a predefined output for the failed module and continues.	Success
Commit	Stops the run and commits changes made so far.	Warning
Rollback	Stops the run and reverts changes in modules that support transactions. This is the default behavior and counts toward deactivation.	Error

Older tutorials may use different handler names, so compare behavior rather than labels. Note from the error handling overview that only unhandled errors, which fall back to Rollback, lead to deactivation. A Skip handler keeps the scenario on but can hide real failures, so pair it with logging.

Platform-specific notes

Credits and operations. Make now bills in credits, which replaced operations as its billing unit. According to Make’s credits announcement, one operation still uses one credit for standard modules, while Make’s built-in AI features can use more. History shows both operations and credits for each run, which helps you find scenarios that consume more than expected.

Automatic retries. Make’s connection error guide explains that when a ConnectionError occurs without error handling, Make pauses scheduling for 20 minutes if incomplete executions are disabled, or retries with a backoff strategy if they are enabled. Rate-limit errors are also retried at increasing intervals when incomplete executions are on, per the rate limit guide.

Sample workflow (hypothetical): The following illustrates an order-reporting scenario and its likely failure points. It is not a description of a specific client project.

Trigger	An e-commerce platform sends a webhook when an order is created (instant trigger).
Applications	E-commerce platform, Make, Google Sheets, a team chat app, and a Make data store or sheet used as an error log.
Data inputs	Order ID, customer email, line items, total, currency, created date.
Processing logic	Filter: continue only if order ID and total exist. Search the reporting sheet for the order ID to avoid duplicates. Add a row with the order data. Post a summary to the team channel.
Expected outputs	One reporting row per order and one team notification.
Failure points	Sheets connection needs reauthorization; platform adds a field and the payload changes; a sale causes a burst of orders that hits rate limits; credits run out mid-month.
Error handling	Store incomplete executions enabled. Retry handler on the Sheets module for temporary failures. A separate route writes failed order IDs and error messages to the log. Because an instant trigger deactivates on the first unhandled error, every module that calls an external service has a handler.
Validation and testing	Send test payloads: a normal order, one missing the total, a duplicate order ID, and a burst of several at once. Confirm row counts, the filter result, the duplicate check, and the log entry.
Business application	Sales reporting stays current without manual exports, and failures are logged instead of disappearing.

Native Make modules handle most of this. Custom development is worth considering when the platform’s webhook payload needs heavy transformation, when order volume makes per-operation costs significant, or when the reporting logic belongs in a database or a custom API integration rather than a spreadsheet.

How to confirm the issue is fixed

The scenario’s scheduling is on, and History shows new runs after the fix with a success status.
Run details show bundles passing through every module you expect, with non-zero counts after each filter.
Each connection shows as verified on the Connections tab.
The destination app contains the correct values, not just a new record.
The Incomplete executions tab is empty or only holds items you have deliberately kept.

Common mistakes to avoid

Reactivating a scenario before reading the error that deactivated it.
Leaving an instant-trigger scenario without error handlers, so one failure turns it off.
Using Skip everywhere to “keep it running,” which hides data loss.
Enabling Process data in order and then ignoring incomplete executions that block the queue.
Retrying incomplete executions without checking whether earlier modules already wrote data.
Testing against live customer records instead of fake payloads and a copy of the scenario.

Prevention and monitoring

Enable Store incomplete executions on scenarios that handle orders, leads, or payments.
Add error handlers to every module that calls an external API, especially in webhook scenarios.
Log failures to a sheet or data store with the record ID, module, and error message.
Review History weekly for warnings, not just errors.
Track credit usage against your plan so a busy month does not deactivate scenarios.

If you also run Zaps, the equivalent checks are covered in Zapier not sending data between apps. When a scenario runs but records still disagree between systems, see CRM data not syncing between applications. Modern Streamline builds and repairs these workflows as part of our Make and Zapier automation services.

Still having trouble with your Make scenario?

Tell Modern Streamline which applications your scenario connects, what it should do, and what History shows instead. We can review your requirements and discuss an appropriate solution.

Get Help With Your Automation

FAQ

Why did my Make scenario turn off by itself?

Make deactivates a scenario after the number of consecutive errors set in Errors before deactivation, immediately after the first error if it starts with an instant trigger, or immediately after fatal errors such as running out of credits. The History tab shows which one happened.

Why is my webhook receiving data but the scenario is not running?

Check that the scenario’s scheduling is on and set to run immediately. If Process data in order is enabled, an unresolved incomplete execution may be holding the queue. Also check for a full queue (400 responses) or rate limiting (429).

Does Make retry failed runs automatically?

For some error types, yes. With incomplete executions enabled, Make retries connection and rate-limit errors at increasing intervals. For other errors, you can add a Retry handler or resolve incomplete executions manually.

Does a filtered bundle count as an error?

No. A bundle stopped by a filter simply does not continue, and the run can still finish with a success status. Check the bundle counts on each module after a run to see where records stopped.

Sources

Tagged Error handling, Make.com, Scenarios, Troubleshooting, Webhooks