Loading tutorials…
Loading tutorials…
Your scenario was working. Now it is failing. The diagnosis sequence specialists run is rarely random — there is a clear order that finds the root cause faster.
Who this is forAnyone running a Make.com scenario that has started failing or never worked. The systematic diagnosis below saves hours of random clicking.
What you'll need
Step 1
Scenarios → [your scenario] → History tab. Click the failed run. The error message tells you which module + what failed.
Open the scenario → History tab (top of the canvas).
Find the most recent failed run (red icon).
Click it. The right panel shows execution details.
Look at "Errors" — the error message names the failed module and the type of failure.
Common error patterns: "Authorization failed," "Bundle data type mismatch," "Module timed out," "Rate limit exceeded."
Note: do NOT skip this step. Random clicking before reading the error message wastes hours.
Step 2
Team → Connections → find the connection used by the failing module → click Verify. Most "Authorization failed" errors are stale OAuth tokens.
Open Team → Connections.
Find the connection used by the failing module. (Module config shows which connection.)
Click "Verify." Make calls the API with the stored credentials.
If verification fails: re-authorize. Click "Reauthorize," walk through the OAuth flow again, save.
For API key connections: paste the key, save, then Verify.
OAuth tokens expire periodically (Google ~90 days if unused, Microsoft ~30 days, Stripe = long-lived). Reauthorize fixes most "auth failed" errors.
Step 3
Organization Settings → Usage. If at 100% of plan limit, scenarios auto-pause until next billing cycle.
Open Organization Settings → Usage.
Check "Operations" usage for current month.
If at or near 100%, scenarios auto-pause. They start running again next billing cycle OR when you upgrade plan.
If you are 80%+ used and 15+ days from billing reset, you will likely hit 100% before reset.
Upgrade plan immediately OR audit scenarios for ops waste (over-polling, unnecessary modules, iteration bloat).
Step 4
Right-click the failing module → "Run this module only." Inspect the input bundle and the resulting error.
On the canvas, right-click the module that History showed as failing → "Run this module only."
Make tries to execute just that module with the most recent input.
If it succeeds in isolation: the problem is in upstream data shape (the original failure was due to specific data that this isolated test does not have).
If it fails in isolation: the module config or the connection itself is broken. Inspect the module fields one by one.
For HTTP modules: check the request URL, headers, body. Compare to API docs.
For native modules: check that required fields are mapped correctly.
Step 5
Often, modules fail because the upstream data changed shape — a field renamed, a value type changed, an unexpected null.
In History, click into the failed run → click the failing module.
View the input bundle that the module received.
Compare to the input bundle of a previous SUCCESSFUL run.
Look for: missing fields, renamed fields, type changes (string vs number), unexpected nulls.
If the source app (e.g., Stripe, Shopify) has updated their API or your custom code changed the data shape, the downstream module needs to be re-mapped.
Re-map the changed field. Save. Re-test.
Step 6
If the error says "Too many requests" or "Quota exceeded," the connected app is throttling you.
API rate limits: most APIs allow N requests/minute. If you burst beyond, they return 429.
In the failing module config, enable "Allow autoretry" with 60s interval. Most rate-limited APIs accept after a brief wait.
For sustained over-limit: lower the scenario polling frequency or implement a counter (data store) to throttle on your side.
Quota: monthly API quota exhausted. Check the app dashboard (e.g., Google Cloud Console for Google APIs) for usage. Upgrade or wait for reset.
Some APIs have per-user quotas. If you authenticate with one OAuth, all requests count against that user. Distribute across multiple connections if scaling.
Step 7
If you cannot diagnose the failure, clone the scenario, simplify, and test piece by piece.
Right-click the scenario → Clone. The clone is paused.
Strip the clone down to just the trigger + failing module. Remove everything else.
Run Once. Does it work in isolation? If yes, the issue is something upstream that the clone removed.
Add modules back one at a time, testing after each. The module that breaks is the culprit.
This bisection technique finds bugs in 15-30 minutes when random debugging takes 3 hours.
Once you find the bug, fix it in the ORIGINAL scenario. Delete the clone.
Common mistakes
Random clicking before reading the error
What goes wrong: You spend 30 minutes clicking through History and connection settings before reading the error message — which would have told you the exact problem in 10 seconds.
How to avoid: ALWAYS read the error message first. Open History → click failed run → read Errors. The message names the module and the failure type.
Reauthorizing without checking which scenarios share the connection
What goes wrong: You reauthorize the Google Sheets connection for one scenario. Discover 6 other scenarios also use this connection — and reauthorization happened mid-run, breaking some.
How to avoid: Before reauthorizing, check Connections → "Used in scenarios." Pause those scenarios first, reauthorize, then resume.
Ignoring ops usage during diagnosis
What goes wrong: You spend 2 hours debugging why scenarios are not running. The answer was 'ops limit hit' visible in 5 seconds on the Usage page. Wasted time.
How to avoid: Check Organization → Usage as one of the first diagnostic steps. If 95%+, that is the issue. Solve that before deeper diagnosis.
Testing in production
What goes wrong: You make experimental changes to a live scenario, breaking it for real customers. Fixing the break takes hours.
How to avoid: For non-trivial fixes, Clone the scenario, fix in the clone, test, then apply the fix to the original. Lower-risk path.
Not checking History before declaring scenarios "fixed"
What goes wrong: You make changes, do a Run Once that succeeds, declare victory. Next scheduled run fails. You missed the test of real data flow.
How to avoid: After a fix, watch History for 24-48 hours. Multiple successful scheduled runs are the proof. One Run Once is necessary but not sufficient.
Recap
Done — what's next
How to set up error handlers in Make.com
Read the next tutorial
Hand it off
Diagnosing Make scenarios is pattern recognition. A specialist has seen the same 12 failure modes hundreds of times and identifies the root cause in minutes. From $14-16/hr — most diagnostic engagements land at $100-300 and fix 3-5 broken scenarios in one session.
See specialist rates
Most common causes (in order): expired OAuth token, source API schema change, ops limit hit, rate limit hit, malformed input from a new edge case. Read the error message first — it usually names the specific issue.
Organization Settings → Usage. Shows ops consumed this month vs plan limit. Scenarios pause automatically when you hit 100% and resume next billing cycle (or when you upgrade).
The API response shape is not what your downstream modules expect. Open the failed run in History, view the raw response from the HTTP module, compare to what you mapped. Field probably moved or was renamed by the API.
Schedule a monthly maintenance scenario that calls each connection (e.g., a lightweight 'Get me' API call) to keep tokens fresh. Plus: set up failure notifications so you catch expired tokens quickly when they do happen.
Patch if the scenario is mostly working and the bug is isolated. Rebuild if the scenario has 5+ patches accumulated, uses outdated patterns (no data stores for dedup, no error handlers), or fails in ways you cannot diagnose. Rebuilding once is cheaper than patching 10 times.
Make
Production scenarios will fail. APIs go down, rate limits hit, data is malformed. The question is whether your scenario recovers gracefully or silently breaks. Error handlers are the difference.
Make
Data Stores are Make's built-in persistent storage. Scenarios are stateless by default; Data Stores give you memory across runs. This is the difference between toy automation and production infrastructure.
Make
Make has 1,500+ native app integrations. For the 10,000+ APIs that are not native, the HTTP module is your universal connector. Learn it once; integrate anything.
Make
DIY Make is a great idea — until it is not. This is the honest framework: when the cost of self-managing exceeds the cost of hiring, and how to tell which side you are on.