What breaks in a Make.com scenario, and what to do about it

A Make.com scenario that has run cleanly for months will eventually meet something it was not built for. A form submits twice. An app it depends on stops answering for ten seconds. Someone renames a column in the spreadsheet it writes to. None of this is exotic. It is the ordinary range of conditions any scenario runs into once it has processed enough orders, leads or reviews to meet the edge cases.

What separates a scenario that copes with this from one that quietly writes the wrong thing into a spreadsheet is not cleverness. It is a handful of decisions made before it goes live: what happens when a trigger fires twice, what a failed module should do next, how a change made elsewhere in the business reaches the scenario before it reaches a person. Most of these cost little to build in and a lot to discover you needed only after something has gone wrong for a month.

The same webhook firing twice

Retries are ordinary. A payment tool, a form or a store that hits a hiccup can resend a webhook that already succeeded once. If the scenario on the other end invoices or emails on every call it receives, a customer gets billed or thanked twice for one order.

The fix is not asking the spreadsheet whether the order is already there. A Google Sheets Search Rows module that finds no matching row returns zero bundles, and a router branch fed zero bundles has nothing to process. It does not throw an error or log anything. The run finishes green, which is the failure mode that looks exactly like success, until someone eventually asks why an order sits in the sheet with no invoice ever raised against it.

A Make data store handles this properly. Before doing anything else, the scenario checks whether the order's own ID is already a key in the store. If it is, the run stops there, on purpose, and nothing downstream fires a second time. If it is not, the key gets written and the rest of the scenario proceeds, one module, placed before a single email or invoice is created.

An app that stops answering, or answers with an error

Sooner or later, the invoice tool will answer a webhook with a timeout instead of a confirmation. Most scenarios have at least one module like this: a call to an outside service that is usually fast and occasionally is not.

Make gives a module five directives to choose between when this happens, set through an error handler attached to that module.

• Ignore skips the bundle that failed and carries on to the next one. The run ends marked as a success.
• Resume supplies a stand-in value for whatever the module would have returned, and everything downstream carries on as if it had succeeded.
• Break stores the run as an incomplete execution and stops there, keeping the data that triggered it rather than discarding it.
• Commit stops the run immediately but keeps whatever was already sent to other services, and marks the execution as successful.
• Rollback stops the run immediately and attempts to undo what earlier modules already did, marking the execution as an error.

Choosing between them

Ignore fits a step where losing one bundle costs nothing, a non-critical notification for instance, and stopping the rest of the scenario over it would cost more. Resume fits a step with a sensible default, treating a lookup that failed as not found rather than crashing the run. Break fits the invoice call: an invoice that fails silently is worse than one a person resolves by hand a few minutes later, and Break keeps the order waiting rather than losing it.

Commit and Rollback matter only to scenarios that touch several services in sequence and need to undo what already happened if a later step fails. Most scenarios never need either directive.

None of these get chosen by leaving the module as it comes. Left alone, a scenario stops on its first error, and every bundle after it in that run is lost.

A column moves, and the scenario keeps going

A scenario that writes into a spreadsheet by column position has no idea the header row changed. Someone reorders two columns to tidy the sheet, or inserts a new one in the middle for a note they wanted to add, and every module mapped to column D is now writing into whatever sits in column D today, not what sat there when the scenario was built.

This fails without an error message, because as far as Make is concerned the write succeeded. The wrongness only shows up later, as an order value sitting in the refund column or a customer's name where the status belongs, by which point several days of writes might carry the same mistake.

No module setting stops a person from moving a column. What limits the damage is writing rarely to a sheet whose structure changes often, appending rows rather than overwriting them where the choice exists, and treating a column added at the far end as the one safe edit, with everything else changed deliberately alongside whoever built the scenario.

Waits that last days, not seconds

Make's Sleep module holds a scenario open for up to 300 seconds. That covers a short pause between two calls to the same app. It is nowhere near long enough for the interval a review request usually needs, which is measured in days.

Building the wait into the scenario itself does not work: the Sleep module tops out at five minutes, and a run that tries to hold on for five days simply times out. Building it into a spreadsheet does. A row gets written the moment a delivery happens, carrying the date it should be actioned. A second, scheduled scenario wakes on its own interval, checks that sheet for rows whose date has arrived, and processes only those. The wait lives in a cell, not in a running scenario, so it survives as long as it needs to.

The scenario that stops firing and nobody notices

A webhook can go quiet because the service sending to it changed settings without telling anyone. A scheduled scenario can be switched off by an accidental click, or by Make itself after enough consecutive errors. Either way the failure is silence: no alert, no red module, nothing in an inbox.

The only real answer is a scenario whose entire job is checking the others. Something that runs on its own schedule, reads the same spreadsheet everything else writes to, and reports when what it finds does not match what should be true: orders logged days ago with no invoice against them, leads assigned to nobody, rows a scenario claimed and then never finished. Built this way, it stays quiet in the ordinary run of things and says something only when a different scenario has already gone wrong, which is the only kind of monitoring worth having. A monitor that talks constantly gets ignored within a week, same as any channel that announces everything.

Kettleford's larger packs ship two scenarios built for exactly this: one reconciles orders against invoices, the other checks for rows a scenario claimed and never finished. Neither has anything to say when the rest of the system behaves.

Break it on purpose before anyone real sees it

The gap between a scenario that works in testing and one that survives contact with actual customers is almost always in what got tested. Sending one clean, well-formed order through proves the happy path. It proves nothing about what happens when a required field is missing, a number arrives as text, or the same webhook fires twice in a row.

Before pointing a scenario at anything real, send it input built to break: a blank field, a duplicate ID, a currency symbol where a number belongs. Then open the execution history and read what each module actually received and sent, not only whether the run finished green. Make keeps that detail for every execution, and reading it is the fastest way to find out whether a module handled the bad case properly or handled it by writing something wrong into a spreadsheet that a person then has to notice and fix by hand.

Do this once for every scenario before it touches a live order, a live lead or a real reviewer.

Questions