Make removes cycles on 1 October: what actually changes

The announcement, and the sentence to read twice

Make is removing a scenario setting on a fixed date:

Make will remove cycles from scenarios on October 1, 2026. Starting from this date, expect the following changes:

The Cycles per run setting in Scenario settings > Advanced settings and related settings are no longer available.

All scenario runs complete one cycle. Scenarios that previously ran several cycles per run process the same data across more runs instead.

[...]

• Cycles removal on October 1, 2026, Make Help Center, updated 13 August 2026

The list has two more entries, and they are the ones that bite quietly - they are quoted further down, where the damage they do is easier to show.

The reassurance further down the same page is accurate, and it is also the reason this will surprise people:

Your scenarios continue running without any action needed from you. Most scenarios behave the same as before.

• Cycles removal on October 1, 2026, Make Help Center

Both sentences are true. Scenarios keep running, and most are unaffected. The gap is that "continues running" and "produces the same result" are different claims, and the second one is the one an owner cares about.

What is a cycle, in one example?

Make's own:

A cycle is one pass through all modules in a scenario. When you set multiple cycles, a pass repeats several times within a single scenario run, pulling data from the trigger module until no data records are left waiting.

For example, your trigger module is set to process 5 emails per run, but your inbox has 10 unprocessed emails. With one cycle, two scheduled runs return all emails. With two cycles, one run does.

• Cycles removal on October 1, 2026, Make Help Center

Hold on to the example, because it contains the whole consequence. Ten emails in one run becomes ten emails across two runs. The work still happens. What changes is how the work is grouped.

Who is actually affected?

A narrow set, and the boundary is documented:

This setting only applies to scheduled scenarios with trigger modules that have a field limiting the number of records per run. Instant scenarios and scenarios with search or action trigger modules don't use it.

• Cycles removal on October 1, 2026, Make Help Center

So instant (webhook-triggered) scenarios are out of scope entirely, as are scenarios whose trigger is a search or action module. What remains is the scheduled scenario whose trigger has a field limiting the number of records per run - common across scheduled triggers in Make, including email, spreadsheet rows, records and files.

Within that set, only scenarios where somebody deliberately set more than one cycle are affected. Make also states how rare it believes this is, and why the setting is going:

Few Makers used cycles, and the setting was more confusing than helpful. In most scenarios that used more than one cycle, multiple cycles rarely took effect.

• Cycles removal on October 1, 2026, Make Help Center

How will you know if it is you?

By receiving an email, which is the part worth planning around:

If your scenarios were among the few using more than one cycle, Make will email you with a list of affected scenarios. If you didn't get an email, none of your scenarios are affected.

• Cycles removal on October 1, 2026, Make Help Center

That is a clear commitment, and it inherits every weakness of email as a control channel. The message goes to the address on the Make account. In an agency setup that address can belong to the client, or to a person who has left, or to a shared inbox with a filter for anything that looks like vendor mail.

"I didn't get an email" is only evidence if you are certain you would have received one.

What breaks, given that nothing errors?

Grouping. Every consequence follows from the same data arriving in more, smaller runs.

• Digests and summaries split. A scenario that collected everything pending and sent one summary now sends one per run. The recipient gets two emails where they used to get one, and nothing in Make reports a problem.
• Aggregators bundle less per bundle. An aggregator's output is scoped to the run it happened in - existing Make behaviour that this change does not alter, but that it now interacts with. Fewer records per run means smaller arrays, which changes what downstream modules receive - and a module that expected "all of today's orders" now receives some of them.
• Counters and totals reset more often. Anything that counts within a run starts over each run.
• Rate-limited destinations get hit differently. More runs at the same schedule means the same total volume in a different distribution, which can help or hurt depending on the receiving API.

None of these produce an error. They produce different output, which is the category of failure that gets discovered by a customer rather than by the platform.

Two more settings go with it, in a different menu

These are easy to miss, because they live in Tools rather than in scenario settings:

Increment function: Reset a value no longer includes the After one cycle option.

Set variable and Set multiple variables: The Variable lifetime no longer includes the One cycle option.

• Cycles removal on October 1, 2026, Make Help Center

If a scenario used those options, its counters and variables had a lifetime tied to a concept that will no longer exist. Worth finding now, because a variable whose scope changed is harder to diagnose after the fact than a scenario that stopped: the run looks normal and the number is wrong.

What Make suggests, and what it does not cover

Two adjustments are offered:

In the trigger module settings, increase the maximum number of results processed per run.

In Schedule settings, shorten the interval so scenarios run more often and process less data each time.

• Cycles removal on October 1, 2026, Make Help Center

The first is the real equivalent: raising the per-run limit to what two or three cycles used to fetch restores the old grouping in one step. Three things to check before relying on it. The trigger has its own ceiling. A larger run costs more operations. And a longer run moves you toward Make's execution time limit, where going over is filed as a warning instead of an error - so the failure this fix can create is the quiet kind.

The second one changes the shape further instead of restoring it: more frequent, smaller runs is the opposite of one large run, and it is the right answer only when the grouping never mattered. It is not free either - every run costs at least the trigger's operation whether or not it finds anything, more runs mean more calls into the receiving system in the same window, and your plan has a minimum interval you cannot go below.

Neither adjustment addresses the variable lifetime change. If a scenario relied on One cycle scope, the fix is to restructure where the value is reset, and no setting substitutes for that.

A short checklist before 1 October

1. Open each scheduled scenario's Advanced settings. A visible Cycles per run field above one means the scenario is in scope. This does not depend on any email arriving.
2. For each one, write down what the run is supposed to produce - one digest, one aggregated array, one total. That sentence is what you are protecting, and it is not written down anywhere in Make.
3. Raise the trigger's maximum results to roughly what the cycles were fetching in total, and confirm the trigger allows that value.
4. Search your scenarios for One cycle variable lifetimes and Increment resets set to After one cycle. These change meaning rather than disappearing loudly.
5. Run once and compare the output to step 2, before October rather than after.
6. Watch the first days of October on the scenarios you touched. The failure mode here is a changed result, so watching means comparing output, not waiting for an error that will not arrive.

Is this worth doing at all if you got no email?

For most accounts, no, and it is worth saying plainly rather than manufacturing urgency. The setting was rare, Make says multiple cycles rarely took effect even where configured, and webhook-driven scenarios are outside the change completely.

The reason to spend twenty minutes anyway is the asymmetry: the check is cheap and visual, and the failure it prevents is the quiet kind that gets noticed weeks later by whoever receives the digest.

When this is a job to hand over

Raising a trigger limit is a two-minute change, and if your scenario is small and you can state what one run should produce, do it yourself.

It stops being that when the scenario is large enough that nobody can say what a single run is supposed to output, when several scenarios feed each other and the grouping of one becomes the input of the next, or when variables with cycle-scoped lifetimes are load-bearing in a flow that touches invoices or customer messages. Reconstructing intended behaviour from a canvas nobody has read in a year is its own kind of work, and it is scoped work with a known price, which is what Fix M is for.

Sources

• Cycles removal on October 1, 2026 - Make Help Center, page updated 13 August 2026, read 18 August 2026. The removal date, the one-cycle behaviour, the definition and example of a cycle, the scope limited to scheduled scenarios with record-limiting triggers, the email notification commitment, the timeline stating where the setting stays visible, the Increment and Set variable changes, and the two suggested adjustments.