Your Make.com scenario stopped running and you have no idea why. Maybe it’s throwing a cryptic “non-existing module” error. Maybe it ran once, burned 400 operations, and silently quit. Maybe it’s just grey and refusing to start. Whatever the shape of the failure, the fix is almost never where people look first.
This is a diagnostic guide, not a list of generic tips. Work the nine fixes below in order — the order matters, because each one rules out a category of failure before the next. Most broken scenarios are fixed by step 3. If you make it to step 9 and it’s still broken, the problem is almost certainly your scenario design, not Make.com itself, and the last section tells you how to rebuild it so this doesn’t keep happening.
Quick answer: why Make.com scenarios stop running
In order of how often they cause silent failures:
- The scenario is switched off (more common than anyone admits)
- You’ve hit your monthly operations quota
- A module references a deleted or renamed upstream module
- An API connection has expired (OpenAI, Google Sheets, WordPress)
- The trigger module has no new data to process
- Data structure has drifted — a column was renamed, a field returns null
- Rate limits on a downstream API are blocking the run
- A filter condition silently evaluates to false
- The scenario is in a zombie state after a hard failure
Work through them in sequence. Don’t skip.
1. Check the scheduler toggle before anything else
Open Scenarios. Look at the toggle next to the scenario name. If it’s grey, it’s off. That’s the entire problem, and it accounts for probably a third of “my scenario stopped working” tickets — including scenarios that disabled themselves after three consecutive errors, which Make does automatically as a safety feature.
Flip it on. Run it once manually. If it runs clean, you’re done. If it errors, carry on.
If the scenario keeps disabling itself within minutes of being turned on, that’s a sign you’ve got a hard error that Make is protecting you from — keep reading.
2. Check your operations quota
Top of the Make.com dashboard. You’ll see a bar showing operations used this month. If it’s at or near 100%, every scenario in your account silently stops running until the monthly reset or you upgrade.
The trap: Make doesn’t send a loud warning. Your scenarios just quietly stop and you think they’re broken. If you’re running content automation at any real volume, the free tier’s 1,000 operations and the Core plan’s 10,000 operations both get burned through fast. A typical content pipeline (Google Sheets → OpenAI → WordPress) uses 3-5 ops per article, so 10,000 ops caps you around 2,500 articles a month — sounds like a lot until you realize a test run burns 20 ops and a failed run with retries can burn 50.
If you’re routinely hitting the ceiling, the fix isn’t “use fewer modules” — the fix is upgrading to the Pro plan, which gives you 10,000 operations at the entry tier and scales to 800,000 at the Teams level. Pro also unlocks priority execution, which matters more than people realize — free and Core plans can queue behind paying customers during peak periods, adding minutes of delay to scheduled runs.
3. Fix broken module references
This is the “references non-existing module [module ID X]” error and it’s one of the most common failure modes after any scenario edit.
What happened: you deleted a module, duplicated one, or rebuilt a section of the scenario. Every module that referenced the deleted one’s output is now orphaned. Make can’t run the scenario because downstream modules are pointing at data that doesn’t exist.
How to fix it:
- Open the module that’s showing the warning
- Scroll through every field — look for purple or orange variable chips that show a module ID or field name in red
- Click into the field and the variable picker opens
- Delete the broken chip
- Find the equivalent field in the new module (usually the one that replaced the deleted one) and click it to insert
- Save the module and the scenario
If you have a dozen modules all referencing a deleted one, this is tedious but unavoidable. Work through them top to bottom. Don’t tick the “Ignore warnings” checkbox — it will let the scenario save, but every run will fail at the orphaned reference anyway, burning operations for nothing.
4. Reauthorize your API connections
Make.com’s connections to external services (OpenAI, Google, WordPress, Anthropic, anything that needs OAuth or a token) expire. Sometimes they expire silently. When they do, the module fails with an authorization error that looks like it’s the module’s fault.
Check the Connections tab in the sidebar. Any connection showing a yellow or red indicator needs to be reauthorized. Click it, then click Reauthorize, then complete the OAuth flow in the popup.
Special cases:
- OpenAI: if you rotated your API key (or it got disabled for hitting billing limits), Make still has the old key cached. You have to go into the connection and replace it with the new key, not just reauthorize.
- WordPress: if you changed a password, reset a user, or updated security plugins that require re-issuing application passwords, the connection dies. Regenerate the application password in WordPress and paste it into Make.
- Google Sheets: if the sheet was moved, renamed, or its sharing permissions changed, the connection may technically be valid but the scenario will fail at runtime because it can’t find the target sheet.
5. Check the trigger has data to process
“Watch” triggers only fire when there’s new data. If your Google Sheets trigger is set to “watch new rows” and there are no new rows since the last run, the scenario starts, sees nothing new, and stops without executing any downstream modules. That’s not a failure — that’s correct behavior. But it reads like a failure because nothing happens.
Check:
- Is the trigger pointing at the right sheet and the right tab?
- Are the “new” rows actually new, or were they already processed on a previous run?
- Did you add the rows above an existing row instead of below? Watch triggers typically look at the bottom of the sheet.
- Is there a filter on the trigger (e.g. “only rows with status = queued”) that’s excluding your test data?
Quick test: add a fresh row with obviously new test data at the bottom of the sheet, then Run once. If it picks up the new row, your trigger is fine and the earlier runs were just correctly finding nothing.
6. Hunt down silent data structure drift
This one is sneaky. Your scenario ran fine for months. Then someone renamed a column in Google Sheets from “keyword” to “Keyword” (capital K). Or the HubSpot field you were reading got archived. Or the OpenAI API response structure changed because you switched from gpt-4 to gpt-4o.
Make doesn’t automatically remap fields when upstream data structures change. The variable chip still says “keyword” and Make dutifully reads that non-existent field and returns null or empty. Downstream modules then fail, often with unhelpful errors like “bundle is empty” or “cannot map null to required field.”
To diagnose: Run once, then immediately click the bubble above each module to see what data actually flowed through it. Look for fields that show “null” or empty when they should have values. Trace backwards until you find the module where data stopped being populated correctly — that’s where the drift is.
Fix by re-running the initial “determine data structure” step in the trigger module (Make has a button for this), then remapping downstream fields to the refreshed schema.
7. Rate limiting from downstream APIs
If your scenario processes a batch of rows and the first few work but the rest fail with “429 Too Many Requests” or “rate limit exceeded,” you’re being throttled by the API you’re calling.
Common culprits:
- OpenAI: tier 1 and tier 2 API keys have low requests-per-minute limits. Pushing 20 articles through in five minutes will trigger 429s.
- WordPress REST API: some security plugins (Wordfence, iThemes Security) rate-limit REST API calls even from authenticated users.
- Google Sheets: has per-user quota limits that rarely hit in normal use but can trigger in batch runs.
Fix: add a Sleep module between the upstream and downstream module, set to 5-15 seconds depending on the API. Yes, this slows the scenario. Yes, it’s necessary. Alternatively, upgrade your OpenAI tier — sustained usage automatically promotes you to higher rate limits over time, but you can also prepay to skip ahead.
For WordPress specifically, check if your security plugin has a REST API rate limit setting. Whitelist your Make.com IP range or disable the rate limit for authenticated requests.
8. Check filter conditions
Filters between modules look inconspicuous but silently gate every run. A filter that says “only continue if word count > 1000” will block every single run if the upstream module is producing articles at 900 words for some reason.
Open every filter in your scenario (they appear as triangles on the connection lines between modules) and check:
- Is the condition evaluating to the value you expect?
- Is the field being compared to actually populated, or is it null?
- Is the comparison type right — “equals” vs “contains,” “greater than” vs “greater than or equal to”?
- Is the AND/OR logic matching what you think it is?
Run once and check the filter bubble — Make shows you whether the filter passed or blocked for each bundle. If everything is being blocked, the condition is wrong.
9. The zombie scenario fix: clone and rebuild
Sometimes a scenario gets into a corrupted state that Make’s UI can’t show you clearly. Symptoms: it saves successfully, shows no errors in the editor, but refuses to run or fails at a module that visually looks fine. You’ve checked everything above and nothing helps.
The fix is brutal but effective:
- Open the broken scenario
- Top right menu → Clone
- Name the clone “[Original name] – rebuild”
- In the clone, delete the problematic module entirely
- Re-add it from scratch (not by pasting, by clicking Add module)
- Reconnect and remap all fields manually
- Save and Run once
- If the clone runs clean, archive the original and promote the clone
Ninety percent of zombie scenarios resolve this way. The remaining 10% are cases where the source data itself is corrupted — which means you’re in step 6 territory, not step 9.
If Make.com keeps failing, here are your alternatives
If you’ve worked through all nine fixes and Make.com is still unreliable for your workflow, it’s worth asking whether Make is actually the right tool for what you’re building. Here’s how the main alternatives compare for content automation specifically:
| Tool | Best for | Entry price | Strength | Weakness |
|---|---|---|---|---|
| Make.com | Visual multi-step content pipelines | Free tier / £8.10/mo Core | Visual editor, generous free tier, huge module library | Ops-based pricing gets expensive at scale, silent failures |
| Zapier | Simple two-step automations | Free tier / £15.48/mo Starter | Largest app library, most reliable at simple tasks | Expensive for multi-step, less flexible than Make |
| n8n (self-hosted) | Technical users who want full control | Free self-hosted / £16.20/mo cloud | No ops limit, unlimited scale, open source | Requires self-hosting or managed cloud, steeper learning curve |
| Pipedream | Developers comfortable with code | Free tier / £15.48/mo Basic | Code-first, very flexible, good at APIs | Not beginner friendly, less visual |
For most content automation use cases — Google Sheets to an AI model to WordPress — Make.com is still the right call. It’s rare that a user switches and is genuinely happier. Nine out of ten times, the issue is scenario design or ops quota, not the tool itself.
Verdict: what to do next
If your scenario was broken when you started reading this, you’ve almost certainly fixed it by step 4. If you’re still stuck at step 9, the problem is the scenario design — rebuild it from scratch with the techniques in step 9, paying attention to step 6 (data structure drift), and it will work.
The deeper lesson: most “Make.com is unreliable” complaints come from scenarios that grew organically, module by module, without a design pass. A well-designed scenario with validation filters, error handling routes, and conservative rate-limit pacing runs for months without intervention. A scenario that was duct-taped together in a single evening fails within weeks.
If you’re building at any real volume — more than a handful of articles a month — the Pro plan pays for itself in saved debugging time alone. Start a Make.com trial here and you’ll get the higher ops quota, priority execution, and advanced scheduling that make automation actually automatic.
Frequently asked questions
Why does my Make.com scenario work when I run it manually but not on schedule?
Almost always one of three things: the scheduler is set to an interval shorter than your paid tier allows (free and Core have a 15-minute minimum), your trigger module has no new data to process on scheduled runs even though it does when you run manually, or the scheduled run is hitting a rate limit during peak hours that manual runs don’t see because they happen at a quieter time.
How do I know if I’ve run out of Make.com operations?
Top of the dashboard, there’s a usage bar. If it’s at 100%, everything has stopped until the monthly reset or a plan upgrade. You can also see exact ops remaining under your organization settings. Make will email you at 80% and 100% but the emails go to spam about half the time.
Can I pause a scenario without losing the pending runs?
Yes. Toggle the scenario off. Pending queued runs pause, and when you toggle back on, they resume. Don’t delete the scenario or remove modules — that destroys the queue.
What’s the difference between “Stop scenario on error” and letting it continue?
“Stop on error” is the default and is usually correct for content pipelines — you don’t want to keep trying to post to WordPress if the content generation failed. Turn it off only if you’re building a scenario where later bundles should continue even when earlier ones fail (rare for content use cases).
Is the Pro plan actually worth it if I’m only running a few scenarios?
For under 1,000 operations per month, stay on free. Between 1,000 and 10,000, Core is fine. Above 10,000 or if you’re hitting ops limits regularly, Pro saves you the hidden cost of failed runs and debugging time — and the priority execution alone usually justifies it for anyone running scheduled content pipelines.
My scenario was working yesterday and broke overnight. What changed?
Usually one of: a connected API updated its schema (OpenAI model deprecation, Google Sheets API change), a password or token rotated, the sheet or sheet tab was renamed, or someone on your team edited the scenario. Check the scenario history log — Make records every edit and every run. The last successful run and the first failed run will bracket the change that broke things.
Hey, I’m Alex — an AI-obsessed reviewer who tests every tool so you don’t have to. Test everything. Trust nothing.
Leave a Reply