How do I tell if it's the workflow or the trigger that's broken?

Click **Execute Workflow** manually. If it runs clean, the trigger is the problem (webhook URL change, expired OAuth, wrong timezone). If it fails the same way by hand, the issue is inside a node.

My workflow shows green but no output appeared. What's that?

Green means it ran without errors, not that it produced output. Click the last node and read its output JSON. A filter or IF node likely returned empty, so the downstream action succeeded on zero items.

Will n8n notify me automatically?

Not by default. n8n's Error Workflow only fires on execution errors, not when a trigger dies, a credential expires silently, or the workflow gets deactivated. Those are the cases that bite agencies.

How long can it stay broken before I notice?

For solo operators managing client workflows, silent breaks (dead trigger, stalled queue, deactivated toggle) stay broken until a client emails, often 2 to 3 days. Loud errors get caught the same morning.

Why does my workflow work in the editor but fail on schedule?

Usually one of three things: the scheduled run uses a different credential than your editor session, the schedule timezone doesn't match your expectation, or an environment variable isn't set in production.

How do I prevent this from happening next time?

Three habits: 60-day OAuth re-auth reminders, explicit timeouts on every HTTP node, and a weekly manual execution on your top client workflows. For the quiet breaks (dead triggers, expired tokens, deactivated toggles), you need something external watching. That's the gap NoCrash closes.

n8n Workflow Stopped Working: The 2am Checklist for Agency Operators

2:11am on a Wednesday in March. Sarah’s phone lights up on the nightstand. Not a page, a Slack DM from a client asking why their lead-routing hasn’t fired since Monday. Three days. She sits up in the dark, opens her laptop, and there it is: the executions list, empty since 11:47pm Sunday. No red error. No email. The workflow just stopped, and the only alarm that went off was a paying client. A different operator on the n8n forum had described the exact feeling a few months earlier:

“My main, perfectly working workflow… suddenly stopped functioning correctly. It triggers on the first message from a user, but never processes the second message.”

— antonvart1990 on n8n Community Forum, 2025-08-15

Sometimes the report is even barer than that:

“Workflow stopped without any reasons.”

— n8n Community Forum thread, 2024

Breathe. There is almost always a reason, and it is almost always one of five. Here’s the order Sarah works them.

The fix that works 40% of the time

Open the workflow. Look at the top-right toggle. If it’s grey, flip it to active. n8n can deactivate a workflow on its own after a crash loop, a restart, or a permissions change, and it does it quietly.

Now click Executions in the left nav, filter to this workflow, and read the most recent entry. Three things it can tell you:

No executions at all since some date. The trigger is dead. A webhook URL changed, a cron never fired, a Gmail trigger lost its OAuth token. Checks 2 and 3 below.
Executions exist but every one is red. A node is failing. Click the newest red run. The offending node lights up. Four times out of five it’s a credential.
One execution running forever, spinner stuck. You’re hung on a long node. Check 5.
Executions are green but nothing landed downstream. This is the sneaky one. Green means the run finished, not that it produced output, and a workflow can finish clean while moving nothing at all. That whole failure mode has its own walkthrough in n8n workflow silently failing.

Before you change a single thing, duplicate the workflow to a -debug copy. Two minutes of copying buys back two hours of undo.

Then click Execute Workflow by hand. Runs clean manually but not on its own? The logic is fine. Your trigger is the problem. That one test cuts the search in half.

Five checks, in the order I actually run them

The toggle is off

Zero executions in the last day, but the workflow looks completely normal when you open it. That’s the signature. Look at the top-right of the editor: green slider means active, grey means inactive. Check the list view too, because the editor sometimes shows you stale state and you’ll swear it’s on when it isn’t. n8n flips workflows off after an error threshold or a restart, and on a shared instance a collaborator will toggle one off to “test” something and never toggle it back. This is the fastest possible fix and the most embarrassing one to have missed. Check it first.

The trigger is broken, not the workflow

Here the manual runs work and the scheduled or webhook ones don’t. For a webhook, re-copy the production URL and ping it with curl or a browser. For a cron, look hard at the timezone on the schedule node, because n8n’s default is not always your server’s local time and a workflow set for 9am can quietly fire at 6am or not when you think. For Gmail or Slack triggers, re-authorize the credential. Triggers are the most fragile thing n8n has, and webhook URLs change after certain edits without telling you.

A credential quietly expired

You’ll see a red execution with a node error about an expired or invalid token, or a credential it can no longer find. Go to Credentials in the left nav, open the one the failing node uses, hit Reconnect, or re-enter the API key. Google OAuth tokens are the worst offenders. They expire on their own, and they get revoked the moment the user changes their account password, with no warning to you and no warning to n8n until the next run fails trying to use them. This one has its own full teardown in n8n credentials expired if the reconnect doesn’t hold.

A recent n8n update broke the node

The tell: it was fine last week, and now one specific node throws something cryptic about a missing parameter or a schema that changed under it. Check your n8n version in the bottom-left. Search the community forum for the node name and that version. Open the affected node, re-select the same options you already had, and save. That re-hydrates it against the current version more often than you’d expect. n8n ships fast, and node parameters and output shapes move between releases without a heads-up.

One node is stuck, the queue is backed up

One execution spins for hours and nothing new ever starts behind it. Open Executions, click the spinning run, find the node that’s yellow. It’s usually an HTTP Request with no timeout, a Wait node with a bad expression, or an AI node throttled by a rate limit. Kill the execution by hand. Then set an explicit timeout on every HTTP node, because on a single-worker setup n8n runs executions in order, and one hung node parks the next fifty behind it.

The bigger question Sarah keeps asking at 2am

All of that gets you running again. None of it answers the thing she stares at the ceiling about: how does she find out next time before the client does? That question has its own answer worth reading slowly, in how to know if your workflow is running and how to prevent silent automation failures, and if you’re staring at a broken automation right now without a clear cause, my automation broke and I don’t know why is the faster triage path. Compare the alert most tools fire when something breaks:

ERR: workflow_execution_failed | node=HTTP Request | status=500 | trace_id=a8f...

with the one that actually helps a non-engineer at 2am:

Your "Client Lead Router" workflow hasn't run since Sunday 11:47pm. The Gmail trigger credential expired.

One you forward to an engineer and wait. The other you fix yourself in three minutes. That second message is what NoCrash sends. It watches your n8n workflows from the outside, every few minutes, and tells you in plain language the moment one goes quiet, not three days later from a client’s inbox. Connect your first workflow free at nocrash.io and the next silent stop reaches you first.

An 11-day gap costs a client. A five-minute gap costs five minutes. You only get to pick which one you build for.

n8n Workflow Stopped Working? Fix It in 10 Minutes