Make.com Testing: How to Test Scenarios Before They Break

What Does Run Once Actually Prove?

Run Once is the best debugging affordance in the category. It executes the scenario against live data and then lets you open every module and inspect the exact bundles that went in and came out. For understanding data shape, nothing beats it.

It still only proves one thing: this scenario worked once, for this bundle, on this data. Three gaps follow from that:

• One path through the graph - A scenario with a router and three routes has at least three outcomes. Run Once exercises whichever route the sampled bundle happened to match.
• No error paths - A successful run never invokes an error handler, so the directive you attached is entirely unverified until something actually fails.
• Real side effects - Run Once is a real execution. Modules that create records create them, and messages that send, send.

Use it as the inspection tool it is, then build deliberate coverage around it. The same distinction between a wiring check and a real suite drives our companion guide to Zapier testing, where the platform gives you noticeably less to assert against. On a code-first platform the balance flips the other way, which is what Pipedream testing covers.

How Does the Bundle Execution Model Work?

Testing Make well requires knowing what a run is made of. Per Make's scenario execution flow documentation, a bundle is the data a module returns, and each bundle moves through a four-phase transaction: initialization, operation, commit or rollback, and finalization.

The detail that matters most for testing is sequencing. That same documentation states that modules process bundles one at a time rather than in parallel, so a second bundle does not begin until the first has finished traversing the scenario.

Three testing consequences follow directly:

• Order is deterministic and therefore assertable - You can seed a known set of bundles and assert on the exact sequence of operations they produce.
• One bad bundle can stall a batch - Without a Skip or Retry handler, a single malformed record stops the run and the remaining bundles never process. Test with a poison record deliberately placed mid-batch.
• Operation counts are a coverage signal - After a run, each module reports how many operations it performed. A module showing fewer operations than the bundles that reached it is the fastest way to spot a branch you never tested.

What Are the Five Error-Handler Directives?

An error handler is a route you attach to a module that runs instead of the failure. The directive at the end of that route decides what happens to the run. Make's error handlers documentation defines five, and the distinctions between them are the whole substance of Make.com testing.

Retry is the only directive that stores an incomplete execution. If your recovery plan depends on replaying failed runs later, any other directive silently discards them.

How Do You Choose the Right Directive?

The choice is a decision you should be able to defend per module, so it is worth writing down as testable logic before you configure anything. Modelling the documented semantics makes the trade-offs explicit:

import test from 'node:test';
import assert from 'node:assert/strict';

// Make's five documented directives, modelled so a suite can assert which one
// a scenario branch should carry before you wire it up in the editor.
const DIRECTIVES = {
  skip:     { continuesScenario: true,  keepsChanges: true,  storesIncomplete: false },
  retry:    { continuesScenario: false, keepsChanges: true,  storesIncomplete: true  },
  resume:   { continuesScenario: true,  keepsChanges: true,  storesIncomplete: false },
  commit:   { continuesScenario: false, keepsChanges: true,  storesIncomplete: false },
  rollback: { continuesScenario: false, keepsChanges: false, storesIncomplete: false },
};

export function chooseDirective({ sideEffectsAlreadyWritten, canSubstituteValue, errorIsTransient }) {
  if (errorIsTransient) return 'retry';
  if (canSubstituteValue) return 'resume';
  if (sideEffectsAlreadyWritten) return 'commit';
  return 'rollback';
}

export function simulate(directive, remainingBundles) {
  const d = DIRECTIVES[directive];
  if (!d) throw new Error(`unknown directive "${directive}"`);
  return {
    bundlesProcessedAfterError: d.continuesScenario ? remainingBundles : 0,
    changesPersisted: d.keepsChanges,
    incompleteExecutionStored: d.storesIncomplete,
  };
}

test('retry is the only directive that stores an incomplete execution', () => {
  const stored = Object.entries(DIRECTIVES).filter(([, d]) => d.storesIncomplete).map(([n]) => n);
  assert.deepEqual(stored, ['retry']);
});

test('commit and rollback differ only in whether changes survive', () => {
  assert.equal(simulate('commit', 3).changesPersisted, true);
  assert.equal(simulate('rollback', 3).changesPersisted, false);
  assert.equal(simulate('commit', 3).bundlesProcessedAfterError, 0);
  assert.equal(simulate('rollback', 3).bundlesProcessedAfterError, 0);
});

test('a half-written invoice must not silently roll back', () => {
  const d = chooseDirective({
    sideEffectsAlreadyWritten: true, canSubstituteValue: false, errorIsTransient: false,
  });
  assert.equal(d, 'commit');
});

Running the full file, which also covers Skip's batch behavior and transient-error routing, gives this actual output:

$ node --test make-directives.test.mjs
1..6
# tests 6
# pass 6
# fail 0
# duration_ms 139.5568

Six assertions in 139 milliseconds, with no Make account involved. This models Make's documented semantics rather than executing a scenario, so treat it as a design check: it forces the per-module decision to be explicit and reviewable before anyone configures a handler in the editor.

How Do You Test Routers and Filters?

A router turns one scenario into several. Coverage collapses fastest here, because a run that takes one route tells you nothing about the others.

• Seed one bundle per route - Three routes means three deliberately crafted trigger records, each confirmed to have taken the route you intended.
• Test the fallback route - Make lets a router carry a fallback for bundles matching no filter. Seed a record that matches nothing and confirm it lands there rather than vanishing.
• Cover filter boundaries - For a filter on "amount greater than 100", seed 99, 100, and 101. Off-by-one filter conditions are invisible in production and trivially caught here.
• Re-verify after adding a route - Routes evaluate in order, so a new route can capture bundles that previously flowed to an existing one.
• Check operation counts per route - After a test batch, a route reporting zero operations is a route your seeded data never reached.

Write the expected route beside each seeded record before running. Deciding afterwards which route "looks right" is how a mis-ordered filter gets rationalized as correct.

What Should You Do With Incomplete Executions?

Incomplete executions are Make's recovery queue. Per the directive definitions above, only Retry creates them: failed runs are stored so they can be retried automatically or manually once the underlying problem is fixed.

Teams treat that queue as a safety net, which it is, and then stop there, which is the mistake. A queue nobody watches is a data-loss backlog with extra steps. Two habits fix it:

• Alert on queue depth, not just on errors - A backlog that grows for three days means the same failure is recurring and the retries are not succeeding.
• Test the replay itself - Force a failure into the queue, fix the cause, replay it, and confirm the downstream write actually landed. A retry that replays into a still-broken mapping just fails again more quietly.

Note: Workflow runs and test runs degrade the same way: a growing pile of retries that nobody reads until something visible breaks. TestMu AI surfaces failure patterns across runs so the trend is obvious before the outage. Try TestMu AI free!

How Do You Catch Silent Failures in Production?

A Make scenario is marked successful once all bundles traverse every module without erroring. Success is a statement about traversal, not about correctness. When an upstream app renames a field, the mapping resolves to empty, every module completes, and the run is green.

Three checks catch what the status never will:

• Operation-count baselines - A scenario that normally performs 400 operations a day and performs 12 has broken, regardless of its status. Alert on the drop.
• A shape assertion inside the scenario - Add a filter immediately after the trigger that only passes bundles with the fields you require. Bundles failing it become visible instead of flowing through empty.
• A canary record - Push one synthetic record through the production scenario on a schedule and verify it arrives correctly at the far end. This is the only check that exercises the entire chain.

The reasoning generalizes past Make. A green trend is only as trustworthy as the assertions that turned each run green, which is exactly why TestMu AI's Test Insights is built as an observability layer over execution records rather than a verdict generator: it aggregates runs into failure-frequency analysis, error-message clustering, and stability trends so a suite that is degrading rather than failing becomes visible. It reads the record your assertions produced and cannot make a weakly-asserted record true, which is the same limitation a Make scenario status has. Our guide to preventing flaky tests covers that detection problem in a test suite.

Conclusion

Open your most business-critical scenario and check how many modules carry an error handler. If the answer is none, attach one to every module that writes data and decide its directive deliberately: Retry for transient failures, Resume where a substitute value is safe, Commit where a partial write must stand, Rollback where it must not. That single pass converts silent, total run failure into a handled outcome you chose.

Then add the shape assertion after your trigger and a baseline alert on operation counts, because those two catch the failures no directive can. If the same workflow automation also drives your release process, our walkthrough of automated cross-browser smoke checks from n8n shows the pattern for making an automation platform run tests rather than only move data.