Most time lost to a broken Make.com scenario is spent looking in the wrong place. The module that reports an error is often not the module that caused one, and a scenario that reports nothing at all can still be quietly wrong. What follows is an order of questions that narrows almost any failure down to a single module before you start reading bundles in detail.
The order matters because each question rules out a whole class of causes. Answer them in sequence and you rarely need all four.
Paste your logs into the Free Analyzer to check this: analyze your logs free.
First question: did the scenario run at all?
Before investigating any module, establish whether a run exists. This sounds trivial and it is the single most common source of wasted debugging time, because “the automation is broken” and “the automation never started” feel identical from the outside.
Open the scenario’s history. The history list records each run’s date and time, trigger, status, and duration, and the statuses you will see are success, warning, and error. If there is no row for the time you expected one, the problem is upstream of every module in the scenario and nothing inside it is worth reading yet.
If there is a row, note two things before opening it: the status, and how far the run got. The history also records the operations consumed and the size of data transferred for each run, alongside its duration, and those numbers are a cheap progress signal. A run that normally consumes forty operations and consumed four did not do most of its work, whatever its status says, which narrows the search to the first few modules before you have opened anything. A run with the usual operation count but a wrong result points the other way, at the values rather than the flow.
The status then tells you which of the next three questions applies.
If it never ran, is it the schedule, the webhook, or the connection?
A missing run has three usual causes, and they are quick to separate.
Start with the scheduling switch. An active scenario runs periodically according to its defined schedule, while an inactive one only runs when manually triggered, and scenarios get deactivated as a side effect of editing far more often than people expect. Confirming that the toggle is on, and that the interval is the one you think it is, takes seconds and rules out the most likely cause. The full set of checks is in the scheduling walkthrough.
If the trigger is a webhook rather than a schedule, the failure mode is different. Contrary to scheduled triggers, which periodically ask a service for new data, a webhook executes immediately once its URL receives a request, so there is no polling interval to blame. Webhooks also expire from disuse: a webhook not connected to any active scenario for more than 120 hours is automatically deactivated. Where the request actually went covers the rest.
Third, check the connection. A connection that is broken, expired, or no longer valid can cause a dependent module to fail at initialization, which can look like the scenario never really started. This is worth suspecting on a schedule, not just once: apps using OAuth 2.0 grant access only for a limited time, so some connections need periodic reauthorization by design.
Where do you start when a run reports an error?
An error status is the easy case, because Make tells you where it happened. Open the run and read the failing module’s input alongside its error. The input matters as much as the message: a module that fails on a malformed value is reporting a symptom whose cause sits in whatever produced that value.
Before trusting the error status at face value, check whether an error handler is attached, because handlers change what the status means. Skip removes the affected bundle and the run ends with a successful status, and Resume replaces the failed output with a substitute value and continues, also ending successful. Both turn a real failure into a green run. Which directive is attached, and what each one costs you when it is the wrong choice, decides whether the status you are reading is trustworthy.
What if it ran green but the output is wrong?
This is the case that eats afternoons, because there is no error to anchor on. The run succeeded, the history looks fine, and the result is still wrong.
Work backwards from the wrong value rather than forwards from the trigger. Opening a run’s details lets you check the output bundles of a specific module, so start at the last module, confirm what it received, and step upstream until the value you are following stops being wrong. The module where wrong becomes right is the module that broke it.
Scenarios that succeed while producing the wrong output usually fail in one of a few specific ways, and the next two sections cover where to look.
What is the fastest general move?
When a scenario used to work, the highest-yield step is not reading the failing run in isolation but putting it next to the last good one. A single run tells you what happened; two runs tell you what changed, and what changed is the cause.
Pick runs that are genuinely adjacent to the break: the most recent run that produced what you expected, and the first that did not. Then compare bundle counts and field values module by module. Comparing a working run against a failing run is the general form of this technique, and it works even on scenarios you did not build, because it needs no knowledge of intent, only two runs.
On Pro and higher plans this gets faster still: fulltext search across execution history can find any term appearing in module outputs, which turns “where did this value come from” into one query.
Where bundles vanish: filters, routers, and iterators
If the failure is that fewer records arrived than expected, three module types account for most of it, and none of them throw an error when they do it.
A filter stops the flow when its condition is not met, so a bundle that stopped matching a filter it used to pass simply never reaches the next module. A router branches the flow into several chains, each processing data according to its route condition, so shifted data can start matching a different route than before and run modules it never used to. Both cases are covered in how filters and routers silently block bundles.
The third is the Iterator. It converts an array into a series of bundles, one per array item, which means its output count is a direct function of the array it was handed. A change in count is therefore almost never the Iterator’s own fault; see what actually moves an Iterator’s bundle count.
Where values change shape: HTTP responses and mappings
If the count is right but the values are wrong, suspect the shape of the data rather than the flow of it.
The HTTP module’s Parse response setting structures output data so mappable items are available after the module runs once, which means your mappings are pinned to the shape the response had at mapping time. When a remote API renames a field, nests a list a level deeper, or changes a type, nothing errors: the mapping simply points at something that is no longer there, and an empty or wrong value flows onward. What happens when a response shape changes covers how to confirm it from a specific run’s raw output rather than from a fresh test call, which may behave differently.
Which checks, in which order?
Run these in sequence and stop at the first one that explains the symptom.
- Is there a run in the history for the time you expected one? If not, the cause is the trigger, not a module.
- If there is no run: is scheduling on, is the webhook still active, and is the connection still valid?
- What status does the run carry, success, warning, or error?
- Is an error handler attached to any module? If so, the status may be hiding a failure.
- On an error: read the failing module’s input, not only its message.
- On a green run with a wrong result: work backwards from the wrong value to the first module where it was still right.
- Compare the failing run against the last working one, module by module, counts first and values second.
- If records are missing, check filters, routers, and Iterator input arrays.
- If values are wrong, check whether an upstream response changed shape.
Where should you start?
| First question | Answer | Where to go next |
|---|---|---|
| Did the scenario run at all? | No run appears in history | Schedule, webhook, or connection |
| Did it run and report an error? | A failed run is visible | Start at the module that threw |
| Did it run green with wrong output? | A successful run with bad data | Compare a working run against a failing one |
| Are records disappearing mid-flow? | Bundle counts drop | Filters, routers, and iterators |
Limitations
This order narrows a failure to a module; it does not tell you what the module should have done, which depends on your scenario’s intent. It assumes the run you need is still in history, which is finite.
It does not cover custom-app-specific behavior, which varies by module. ScenarioTrace’s Free Analyzer automates the run-comparison step described above and is deterministic-first with AI-assisted reasoning as a fallback, so treat its output as a diagnosis to confirm against your own history rather than a verdict.
This article was drafted with AI assistance and checked against cited sources through ScenarioTrace’s editorial workflow.
Make and Make.com are trademarks of their respective owner. ScenarioTrace is an independent tool and is not affiliated with or endorsed by Make.