Make Scenario Not Running? 10 Real Causes and How to Fix Each One

You open the scenario and everything looks correct. The modules are connected, the mapping is right, the trigger points at the account it always pointed at. You press Run once and the whole thing completes in four seconds, exactly as designed. Then you close the tab, wait an hour, and nothing has happened. A Make scenario not running on its own while working perfectly by hand is one of the more maddening problems in automation, because the part you can test is the part that was never broken.

I build automations for course platforms, membership sites and the tools that feed them, and this specific failure comes up constantly. The reason is structural. Pressing Run once bypasses roughly half of what has to be true for a scheduled run to happen at all. The schedule, the credit balance, the plan limits, the account time zone, the trigger’s own memory of what it already processed: none of that is exercised when you run a scenario by hand. So the manual test passes, tells you nothing, and sends you off inspecting modules that were fine all along.

How Does Make Actually Decide to Run a Scenario?

A scheduled run is not one decision. It is a short sequence of separate checks, each owned by a different part of the platform, and the run only happens if every one of them passes. Knowing the sequence is what turns this from guesswork into a five minute diagnosis.

First, the scheduler asks whether this scenario is switched on. If it is, it asks whether the organization has credits to spend, since a run costs credits and an empty balance stops the queue. Then it checks the interval you asked for against the floor your plan allows. Only after all of that does the trigger module actually go and look at the connected service. And the trigger has its own memory: it knows what it processed last time and asks only for what came after that. If the answer is nothing new, the run ends there without touching a single downstream module.

The distinction that matters most here is between the two kinds of trigger, and Make’s own documentation on module types draws it clearly. A polling trigger goes and checks the source on your schedule, like refreshing a page to see whether anything arrived. An instant trigger is a webhook: the other service tells Make the moment something happens. They fail in completely different ways, so identifying which one sits at the top of your scenario decides which half of this article applies to you.

Pressing Run once skips the first three checks entirely and, in some cases, changes the fourth. That is precisely why the manual test is so misleading, and why I no longer treat “it works when I run it” as diagnostic information at all.

Cause 1: Is Scheduling Switched On, and Was the Scenario Saved?

This accounts for more of these tickets than everything else combined, and it is worth checking properly rather than glancing at. The scheduling toggle sits at the bottom left of the scenario editor and again on the scenarios list. Off means the scenario exists, is fully configured, is testable by hand, and will never run on its own.

There are two ways people end up here without realising. The first is editing. You open a working scenario to change a field, and somewhere in the process the toggle goes off or the scenario gets left in an edited state that was never saved. Changes in Make apply to the running version only once you save, so a schedule you changed ten minutes ago and admired on screen is not the schedule the platform is using.

The second is misreading what the schedule says. Make’s scheduling documentation lists several types beyond a simple interval: once, every day, days of the week, days of the month, specified dates, on demand, and immediately for triggers that support it. On demand is the one that catches people, because it is a legitimate setting that means “only when something calls this scenario”. A scenario set to on demand is switched on, correctly configured, and permanently idle.

Cause 2: Is It Running Fine and Hiding Its Check Runs?

Before you change anything, rule this one out, because a large share of “my scenario stopped” reports turn out to be a scenario that never stopped at all. A polling trigger runs on schedule, asks the source whether anything new has arrived, and gets told no. That is a complete, successful, entirely normal execution. Make calls it a check run.

The problem is that the History tab hides check runs by default. So you open History expecting a row every fifteen minutes, see the last real execution from Tuesday, and conclude the scenario has been dead for three days. It has been working the whole time and finding nothing to do, which is a very different problem with a very different fix.

Once you can see the check runs, the diagnosis becomes straightforward. Check runs present and recent means the schedule is healthy and the question moves to why the source has nothing new, which is usually a filter at the source, the wrong folder or list selected in the trigger, or the epoch problem covered further down. No check runs at all means the scheduler is not reaching this scenario, and the causes below apply.

Cause 3: Did Make Deactivate the Scenario After Repeated Errors?

Make switches scenarios off by itself, deliberately, and it is easy to miss that this happened. A scenario that errors repeatedly is burning credits to fail, so the platform stops it rather than letting it run all month.

Two behaviours are worth knowing precisely, and Make sets them out in its guide to fixing errors and warnings. Non fatal errors, the account validation and bundle validation and data error family, pause the schedule for twenty minutes after the module fails, and enough repeats disable the scenario. Fatal errors behave differently: a data size limit error, an inconsistency error or an operations limit error disables scheduling immediately, regardless of how many consecutive errors came before it. One bad run is enough.

How many consecutive errors it takes is not a fixed platform constant, it is a setting on your scenario. Open the scenario settings and you will find Errors Before Deactivation, which defines the maximum number of consecutive errors tolerated before scheduling is switched off. Read what yours is actually set to rather than assuming, because the answer changes what you should do next.

Make emails you when this happens. Those emails routinely land in a shared admin inbox nobody reads, or in spam, which is how a scenario ends up switched off for a fortnight with everyone assuming it is running.

Cause 4: Have You Run Out of Credits?

If every scenario in the organization went quiet at the same moment, stop looking at any individual scenario. This is an account level stop, and the usual reason is credits.

Make replaced operations with credits as its billing unit in August 2025, converting existing balances one for one. The consequence of running out is stated plainly on Make’s own pricing page: your scenarios will not continue to run until credits are added again. Nothing is broken, nothing is misconfigured, and the scenarios still show as switched on. They simply have nothing to spend.

Two details make this harder to spot than it should be. Make sends usage notifications at seventy five and ninety percent, which is genuinely useful if those emails reach a person who acts on them and useless if they go to a billing address nobody monitors. And incoming webhook data queues up while you are out of credits and processes once credits are restored, which produces a confusing burst of very late executions the moment you top up.

Cause 5: Is the Interval Shorter Than Your Plan Allows?

The scheduling interval is not entirely yours to choose. Each plan has a floor, and asking for something below it does not get you what you asked for. On the free plan that floor is fifteen minutes. Every paid tier drops it to one minute.

This causes a specific and very confusing symptom. You set a scenario to run every five minutes on a free account, watch it not run every five minutes, and reasonably conclude the schedule is broken. It is not. It is being held at the plan minimum, and the gap between the schedule you configured and the schedule being applied is invisible unless you know to look for it.

There is a ceiling at the other end too. Make rate limits how often scenarios start, with a default maximum of one hundred runs per minute across the organization, and requests beyond that are queued and processed gradually rather than dropped. On a busy account with a lot of instant triggers, that queueing looks exactly like lateness.

Cause 6: Have You Hit the Active Scenario Limit?

The free plan allows two active scenarios. Not two scenarios, two switched on at the same time. You can build as many as you like and only two of them run.

The way this surfaces is what makes it hard to diagnose. You switch on a third scenario, get a message, dismiss it while thinking about something else, and carry on. The scenario sits there looking configured and does nothing. Worse, some people work around the limit by turning one scenario off to turn another on, which quietly turns a permanent automation into a manual one that only runs when somebody remembers to enable it.

Every paid tier removes the cap, which is why this cause disappears the moment an account moves off free. If you are troubleshooting somebody else’s account, checking the plan takes five seconds and rules the whole category in or out.

Cause 7: Is the Schedule Running in a Different Time Zone Than You Are?

This one does not stop a scenario. It runs it at the wrong time, which looks identical from where you are sitting: you check at nine in the morning, nothing has happened, and the scenario appears broken. It ran at four, in a time zone you never set.

Make separates two settings that sound like the same thing, and its time zone documentation is explicit about the split. The organization time zone decides when scheduled scenarios execute: a schedule of four in the afternoon means four in the afternoon in the organization’s time zone. Your own user time zone changes nothing about execution and only affects how Make displays dates and times to you.

The practical result is that two people looking at the same scenario see different times and both are right. It also means a team spread across regions gets a scenario running on the schedule of whoever created the organization, which is rarely a deliberate decision and often nobody’s local morning.

Cause 8: Has the Trigger Already Moved Past Your Test Data?

Here is the cause that produces the exact symptom in this article’s opening: works on Run once, does nothing on a schedule. A polling trigger keeps a marker for where it last got to, and every scheduled run asks the source for records after that marker.

You choose that starting point once, with the Choose where to start option on the trigger module, and Make’s documentation is clear that the choice only applies to the first run. Every subsequent run tracks changes made since the previous run. So if you set up the scenario, ran it manually a few times while testing, and then scheduled it, the marker has already advanced past the test record you keep expecting it to pick up. The scheduled runs are working correctly and finding nothing, exactly as instructed.

The same mechanism explains a scenario that stops noticing a specific subset of records. If items are added to your source with an older date or lower identifier than the marker, they are behind it and will never be seen. Imported historical data and back dated rows disappear into that gap constantly.

Cause 9: Is an Incomplete Execution Holding the Queue?

Two scenario settings interact here in a way that stops everything, and neither one is obviously the culprit on its own. Store Incomplete Executions saves a failed run instead of discarding it, so the data can be retried rather than lost. Process Data in Order makes each execution finish before the next one starts.

Turn both on and the behaviour is documented directly in Make’s scenario settings reference: if there is an incomplete execution, no new runs are processed until all incomplete executions are resolved. That is a deliberate protection against processing records out of order, and it is completely correct behaviour. It also means one stuck record from last Thursday blocks every run since, and the scenario looks dead while behaving exactly as configured.

There is a storage ceiling as well. The number of incomplete executions an organization can hold depends on your usage allowance, and a related setting, Discard Data if Storage is Full, decides whether the scenario keeps running by throwing failed data away once that folder fills up. Off means safety at the cost of a growing blockage. On means continuity at the cost of losing whatever failed.

Cause 10: Is the Webhook Queue Full or Attached to the Wrong Scenario?

Everything above assumes a polling trigger. If your scenario starts with a webhook, the failure modes are different and the fixes are different too.

When a call arrives and cannot be processed immediately, Make holds it in that webhook’s processing queue. The queue is sized by your subscription, and the numbers in Make’s webhooks documentation are worth knowing before you need them: for every ten thousand credits licensed per month you get up to six hundred and sixty seven items in each webhook’s queue, capped at ten thousand items. Once a queue is full, incoming data over the limit is rejected. Not queued, not delayed. Rejected.

The other webhook failure is quieter. A webhook belongs to a scenario, and duplicating a scenario, rebuilding one, or pasting a webhook address from an old build leaves the sending service posting to a webhook that is attached to something else. The sender gets a success response, so nothing looks wrong from that end at all, and the scenario you are watching never sees a single call.

Make Scenario Not Running: Which Check Comes First?

Run these in order. Each step either finds the cause or removes a whole category from the search, which is faster than opening settings screens at random. The first three take under two minutes together and account for most of what I find.

1. Establish the scope. One scenario or all of them. Every scenario going quiet at once points at credits or the account, never at a module.
2. Check the scheduling state on the list view. On or off, for real, on the scenarios list rather than in the editor.
3. Unhide check runs in History. If check runs are arriving on schedule, the scheduler is healthy and the problem is at the trigger or the source.
4. Read the last few executions before the silence. A run of errors ending in nothing means Make deactivated the scenario for you.
5. Check the credit balance and the reset date. An empty balance stops scheduled runs across the whole organization.
6. Compare the interval against your plan’s floor. Fifteen minutes on free, one minute on every paid tier.
7. Read the organization time zone. If runs are happening but at unexpected hours, this is almost always why.
8. Open the incomplete executions folder. Anything sitting in there blocks new runs while Process Data in Order is on.
9. For webhooks, verify the address and the queue. Confirm the sender posts to this scenario’s webhook, then check the queue is not full.
10. Only then reset the trigger’s starting point. Move the marker back and wait for a real scheduled run, not a manual one.

The ordering is deliberate. Steps one through five cost almost nothing and cover the causes that stop the scenario completely. Steps six through ten deal with scenarios that are running and producing the wrong outcome, which is a slower category to diagnose and worth reaching only after the fast checks have come back clean.

What If the Scenario Runs but Stops After the Trigger?

This is a different problem wearing the same clothes, and it is worth separating out because the whole diagnostic list above is the wrong list for it. Executions appear in History. The trigger returns data. Nothing downstream happens, and no error is reported.

A filter is the usual answer. Filters sit between modules and silently discard bundles that do not match, which is their job, and a filter comparing a text value against a number, or checking a field that arrives empty, rejects everything without complaining. Open the execution in History and click the filter: Make shows how many bundles reached it and how many passed. Zero passing on a run that fetched twenty records tells you where to look immediately.

Router paths behave the same way. Every route has its own filter, and a route whose conditions never match is a dead end that costs nothing and reports nothing. This is the same class of problem as an automation platform receiving the right data and refusing to act on it, which I went through from the other side in the guide to a Zapier Zap not triggering, where the filter and the trigger get blamed for each other’s behaviour constantly.

Why Does a Stopped Scenario Go Unnoticed for So Long?

Because a scenario that does not run produces nothing to notice. A failing scenario generates errors, emails and a red row in History. A deactivated one generates silence, and silence does not appear on a dashboard built to show what happened.

The work an automation does is usually invisible when it goes right, which is the entire point of automating it. Nobody watches the leads arriving in the CRM or the enrolments syncing to the course platform, because watching them was the job the scenario replaced. That means the first signal is almost always secondary and late: a customer asking why they never got access, a report with a hole in it, a monthly number that came in soft.

The platform’s own notifications are real and do get sent, for deactivation and for credit usage, but they arrive by email into whatever inbox the account was created with. On the accounts I get called into, that address is often a shared admin mailbox or a former team member’s, and the warnings have been arriving correctly for months into somewhere nobody reads. The failure is not that Make stayed quiet. It is that the message had nowhere useful to land.

How Do You Stop Scenarios Quietly Switching Themselves Off?

Handle the errors that are predictable. Any module that talks to an external service will fail sometimes, and an unhandled failure counts toward deactivation while a handled one does not. Adding error handlers to the two or three modules that actually break is a short job that removes most unplanned deactivations.

Send the platform’s notifications somewhere a person reads. Point the organization’s email at a monitored inbox rather than the address the account was opened with, and treat a deactivation email as an incident rather than a newsletter. This costs nothing and turns a two week outage into a same day fix.

Build a heartbeat for anything that matters. A scenario that posts to a channel each morning saying it ran gives you a positive signal instead of relying on the absence of a negative one. It is a few minutes of work and it inverts the whole problem: you stop needing to notice silence, because the noise stops instead.

Then review the interval honestly. Most scenarios I inherit poll far more often than the work requires, which burns credits, brings the balance down early and stops everything else in the account. Matching the interval to how quickly the result is genuinely needed is the single change that prevents the most common account level stop, and it usually costs nothing in practice. If you want a second pair of eyes on how a stack of these fits together, that is the kind of thing my automation and integration work covers.

Frequently Asked Questions

Why does my Make scenario work on Run once but not on schedule?

Because Run once skips most of what a scheduled run has to clear. It ignores the scheduling switch, the credit balance and the plan’s interval floor, and it does not depend on the trigger’s stored starting point in the same way. The most common real answer is that the trigger’s marker has already advanced past your test record during earlier manual runs, so the scheduled runs are checking correctly and finding nothing new. Reset the starting point on the trigger, create a genuinely new record, and wait for a real scheduled run rather than pressing Run once again.

Why did Make deactivate my scenario by itself?

Repeated errors. Non fatal errors pause the schedule for twenty minutes each time and enough of them in a row disable the scenario, while fatal errors such as a data size limit, an inconsistency error or an operations limit error switch scheduling off immediately regardless of how many came before. How many consecutive errors it takes is set per scenario under Errors Before Deactivation in the scenario settings. Fix the underlying error before switching it back on, otherwise it deactivates again on the same pattern.

Why is my scenario history empty when the scenario is switched on?

Usually because check runs are hidden. When a polling trigger finds no new data, the run still happens and still counts as an execution, but History hides those rows by default. Click the arrow at the top right of the History panel and switch Hide check runs off. If check runs then appear at your scheduled interval, the scheduler is working and the question becomes why the source has nothing new to give it.

What happens to my scenarios when I run out of credits?

They stop running until credits are added again. The scenarios stay switched on and configured, so nothing looks wrong on the scenario itself, which is why an account wide stop gets misread as a scenario fault. Usage notifications go out at seventy five and ninety percent of your allowance. Incoming webhook data queues while you are out of credits and processes once the balance is restored, which produces a rush of late executions the moment you top up.

Can I run a Make scenario every minute on the free plan?

No. The free plan’s minimum interval between scheduled runs is fifteen minutes, and every paid tier lowers it to one minute. Setting a shorter interval on a free account does not produce a shorter interval, which is why the schedule looks like it is being ignored. The free plan also caps you at two active scenarios at a time. If you need near real time behaviour without upgrading, redesign around an instant trigger, since a webhook fires on the event itself rather than waiting for the next poll.

Why does my scenario run at the wrong time of day?

Because scheduled scenarios execute in the organization’s time zone, not yours. Your own user time zone only changes how Make displays dates and times on screen, so two people in different countries see different clock times for the same run and both readings are correct. Open the organization settings, read its time zone, and either change it or offset the individual schedule to compensate. Check it again after each daylight saving change.

If you have worked through all ten and the scenario is still idle, the cause has usually moved outside Make. A connection whose authorisation was revoked at the other service, which fails at the moment of use rather than when you look at it. An account restriction or a rate limit at the connected app that returns nothing rather than an error. A trigger pointed at a folder, list or view that somebody renamed or emptied. Those are worth investigating once the ten above are genuinely ruled out, and not before.

The pattern underneath nearly all of it is the same one that makes this problem so frustrating. A scheduled run is a chain of separate permissions, and the scenario canvas shows you only the last link. The switch, the balance, the plan floor, the time zone and the trigger’s memory all sit somewhere else, and every one of them can stop a run without marking the canvas in any way.

Read the chain from the left rather than the right, and the answer is usually a setting you never opened rather than a module you have now rebuilt three times. The same reasoning applies across every tool in this category, which is why the checks look so similar to the ones in the guide to an ActiveCampaign automation not triggering.