Your Make scenario timed out, and Make called it a warning

The run that stopped halfway through

Somewhere around the middle of the job, the scenario stopped. Not because an app was down, not because a field was empty. It stopped because it had been running for longer than your plan allows, and Make cut it off.

Make did send you an email about it. That is the part worth sitting with, because the email is why this problem survives for months: it arrives with the subject "Encountered warnings in scenario", it recommends that you pay attention, and then every other mechanism in the system behaves as though nothing happened. The schedule stays on. The error counter does not move. No data is kept for a retry. Twelve minutes later the next run starts, and it will end the same way.

Here is the body of the one we received, verbatim, from a scenario we ran to the ceiling on purpose:

Your scenario timeout-test has encountered warnings.

We recommend that you pay attention to these warnings:

The details of the warnings are:

Execution was FORCED to stop because MAXIMUM EXECUTION and OVERLAY TIMEOUT [10 minutes] had elapsed

• Make notification email, noreply@eu1.make.com, 17 August 2026

Compare it to the email the same account got from a scenario with a genuine error, twenty minutes earlier:

Your scenario timeout-test has encountered an error.

The scenario has not been paused and continues to run according to your settings. Nevertheless, you should pay attention to the issue.

• Make notification email, noreply@eu1.make.com, 17 August 2026

Two different categories, two near-identical envelopes. Both say "pay attention", neither says "half your job did not run", and only one of them feeds the machinery that eventually switches a broken scenario off.

What does "warning" actually change?

Everything that would otherwise save you. The documentation is explicit:

When a module in a scenario returns a warning, your scenario keeps running and stays enabled. A warning doesn't disable the scheduling of your scenario and warnings don't count into the number of consecutive errors.

• Introduction to errors and warnings, Make Help Center, updated 13 August 2026

And here is the line that puts your timeout in that category. The same page lists what causes a warning, and the third item is the one that hit you:

The following are the most common scenarios that cause a module to return a warning:

• When a module outputs an error, but you have enabled the storing of incomplete executions in the scenario settings.
• When the data store used in a scenario reaches its capacity limit.
• When the execution time of a scenario run exceeds the duration limit of your subscription.

Running out of time is filed as a note. The note does get emailed, and there it stops: the schedule keeps its next slot, the counter stays where it was, and nothing about the run is kept.

Where can you see it at all?

In the scenario's History tab. Open the scenario, switch from Diagram to History, and read two columns: Status and Duration.

Our timed-out run shows up there as a single line: status Warning, duration 10 minutes, 3 operations. The row above it is the next scheduled run, already going, because nothing about the warning interrupted the schedule.

Why doesn't the scenario switch itself off?

Make does have a brake. It just is not connected to this pedal.

Every scenario carries a setting called Errors before deactivation, and on a new scenario it is set to 3. The description in the scenario settings dialog reads:

Define how many consecutive times the scenario can end in an error before it's automatically deactivated. Scenarios with instant triggers deactivate after the first error.

• Make scenario settings dialog, Advanced settings, checked 17 August 2026

Two things follow. First, a scheduled scenario gets three consecutive genuine errors before Make turns it off, while a webhook-driven one gets a single one. Second, and this is the whole problem, a timeout never contributes to that count at all, because warnings "don't count into the number of consecutive errors".

The counter is doing its job. It is counting a category of event that your scenario is not producing.

Won't incomplete executions catch it?

No, and this is the part that surprises people who already did the responsible thing and turned that setting on.

Storing incomplete executions is what lets Make keep the data from a failed run so it can be retried or reviewed by hand. It defaults to No on a new scenario, and it is not even visible until you flip the Advanced settings toggle at the bottom of the scenario settings dialog. So most scenarios do not have it.

But turning it on does not cover a timeout. Make lists the cases that never produce an incomplete execution, and the third one is ours:

However, some errors don't create an incomplete execution:

• When the error happens on the first module in the scenario.

• When your incomplete executions storage is full.

• When the scenario runs longer than the scenario run duration limit.

• When an error happens during the initialization or rollback scenario phase.

• Errors that don't create incomplete executions, Make Help Center

There is nothing stored, so there is nothing to retry and nothing to review. The work that did not happen simply did not happen.

Will Make retry the run by itself?

Also no. Automatic retries exist, but they cover three specific error types:

Make automatically retries incomplete executions that have been created because of:

• RateLimitError

• ConnectionError

• ModuleTimeoutError

• Automatic retry of incomplete executions, Make Help Center

ModuleTimeoutError is worth a second look, because the name is close enough to cause real confusion. That one is a single module waiting too long on a third-party API. Yours is ExecutionInterruptedError: the whole scenario run exceeded the plan's duration limit. Different event, different category, and it is not on the retry list.

Which is consistent once you line the two rules up. Retries operate on stored incomplete executions, and a timeout never creates one.

For the record, when a retry does apply, the schedule runs eight attempts with a widening gap: 1 minute after the original run, then 10, 10, 30, 30, 30 minutes, then two attempts three hours apart, with the last one landing 7 hours 51 minutes later. Make runs at most three of them in parallel per scenario.

What is your actual time limit?

Check it in your own billing page. The numbers people quote in forums are out of date, and two of them contradict each other. Inside the account, Organization → Subscription prints the limit as part of each plan:

Checked 17 August 2026 on a live Free organization in the eu1 zone.

Then check what actually stops your run, because it may not be that number. On the Free account above, the billing page prints 5 minutes. The run went on past six minutes, past eight, and was cut off at ten. The email named the figure it enforced:

Execution was FORCED to stop because MAXIMUM EXECUTION and OVERLAY TIMEOUT [10 minutes] had elapsed

• Make warning email for execution 1b43a242088648a2960a940b669e9fb2, 17 August 2026

The history row agrees: duration 10 minutes. So the plan page and the engine disagree by a factor of two, and both are Make's own numbers. Whatever you plan around, get the figure from a run that actually hit the wall rather than from the marketing table.

The forum shows the same confusion, and it is older than our test. The 40-minute thread and the 45-minute one sit side by side, and in the first of them a user posted our exact wording - [10 minutes] - back in December 2023, called the mismatch "conflicting information", and got no answer. He never says which plan he was on, and nobody in the thread ties the figure to one, so the honest reading is narrow: the number the platform enforces is not dependably the number on your billing page, and it has been that way for years. Both forum figures, 40 and 45, come from users rather than from Make staff.

Two more Free-plan limits matter for this problem: two active scenarios at a time, and a minimum gap of 15 minutes between scheduled runs. On Core the minimum gap drops to 1 minute.

What we saw on a live account

Assuming any of this would have been easy, so we ran it. On a Free organization we built the smallest scenario that cannot finish in time: a Repeater set to three iterations feeding a Sleep module set to 300 seconds. Fifteen minutes of intended work, scheduled every 15 minutes.

What happened, in order:

1. The run started at 19:04:45 and kept going well past the 5 minutes printed on the plan page.
2. At the ten minute mark Make stopped it. The history row reads: status Warning, duration 10 minutes, 3 operations.
3. An email arrived, subject "Encountered warnings in scenario timeout-test", naming a 10 minute limit.
4. The scenario stayed enabled. The next scheduled run started at 19:16:37, heading for exactly the same wall.
5. The Incomplete executions tab stayed empty, matching the documentation: a run past the duration limit does not create one.

Three things there are worth keeping. The enforced limit was not the published one. The run was cut mid-work and nothing was preserved. And the scenario went straight back into the schedule, which is what turns one bad night into a standing condition.

For contrast, the same account produced a real error earlier, from a scenario missing a required parameter. That one showed as status Error, duration "less than 1 sec", with the cause spelled out in the log (Missing value of required parameter 'step'), and it counts toward deactivation. A genuine error announces itself and eventually stops the scenario. A timeout does neither.

Five checks for tonight

1. Open History and sort by duration. You are looking for runs that all stop at the same number of minutes. When several land on the same figure, that figure is your ceiling.
2. Read the status column, not the colour you remember. Warning and success are different states, and a warning row is the one this whole article is about.
3. Open scenario settings and turn on Advanced settings. Check where Store incomplete executions actually sits. On a scenario nobody has touched, it is No.
4. Check Errors before deactivation. The default is 3, and it only ever sees genuine errors. If your scenario runs on a webhook, one error is enough to switch it off, which is a different failure mode worth knowing about.
5. Compare the work against the clock. If the job grew this year (more rows, more customers, more files) and the limit did not, you are heading for the ceiling on a schedule, and the first night it happens will look like any other night.

What actually fixes it

The goal is not to make the run faster in some vague sense. It is to make sure no single run has to carry the whole job.

1. Cut the work into batches the scenario can finish. Process a bounded number of records per run and let the schedule come back for the rest. Instead of "sync everything", you want "sync the next 200".
2. Make the trigger incremental. A scenario that always starts from the beginning of the table gets slower every week by design. One that picks up where it left off stays the same size no matter how much data accumulates.
3. Move the heavy step out of the loop. Fetching, transforming and writing inside a single iteration multiplies every inefficiency by the number of rows. Fetch once, then iterate.
4. Add a signal you own. Since Make will not tell you about a timeout, have the scenario write a completion marker at the end (a row, a timestamp, a message) and watch for its absence. A run that is cut off never reaches its final module, so the missing marker is your alarm.
5. Raise the ceiling only when the shape is right. Moving from 5 to 40 minutes buys real headroom, and if the job is genuinely large that may be the correct answer. It is the wrong answer when it just delays the same failure until the data grows again.

What does not fix it

• "Process data in order" is not a safety net for this. The setting is No by default, and its effect is the opposite of protection: with it on, one unresolved incomplete execution stops new runs from being processed until you clear it. It changes what happens after a failure, not whether a timeout is reported.
• Error handlers do not catch a timeout. Handlers attach to modules and react to module errors. Running out of time is not something a module returned.
• Turning on incomplete executions does not cover it. As above: no incomplete execution is created for a run that exceeds the duration limit.
• Reading the notification email is not monitoring. The email does arrive, and that is exactly why it stops working: it looks like the other Make emails, it says "we recommend that you pay attention", and after the third one it is a thing you archive on the way to something else. An alert that never escalates trains you to ignore it. The mirror image lives on Zapier, where a runaway loop burns the monthly quota in green, successful runs and sends nothing at all until the quota is gone.

When this is worth handing to someone

If the scenario is a one-off that got too big, the batching fix is an afternoon of work and the checks above will tell you where to start.

It stops being a small job when the run is feeding something the business depends on and nobody can say which records made it through last week, or when the same scenario has been quietly half-finishing for long enough that the data behind it has drifted. That is a repair with a known scope: find the ceiling, split the work, add the signal, reconcile what was lost.

Sources

• Introduction to errors and warnings - Make Help Center, updated 13 August 2026. Definitions of errors and warnings, the email notification rule, and the list of what causes a warning.
• Errors that don't create incomplete executions - Make Help Center. The list including runs that exceed the duration limit.
• Automatic retry of incomplete executions - Make Help Center. Which error types Make retries and the backoff schedule.
• MAXIMUM EXECUTION TIMEOUT [40 minutes] & Error handler notification - Make Community. Example of the figures circulating in the forum; the 40-minute figure comes from a user, not from Make staff, and the thread ends unresolved.
• Scenario timeout (max 45 min) -> workarounds? - Make Community. The competing figure, in the same forum.