I have a workflow where the following nodes (see screenshot) have been receiving Inputs during live executions but have failed to emit their Outputs, thus “stopping” parts of the workflow from progressing. Further, no errors are being reported. The Inputs are not empty or null, so the nodes should be producing outputs.
The nodes work during during manual testing without issue using pinned data.
In terms of troubleshooting, I’ve:
Cleared my browser cookies
Started editing my workflow from an incognito browser window
Replaced the Edit Field node to test if the stoppage at that point was due to a “corrupted node” – it didn’t “fix” the issue
Duplicated the workflow in case the entire workflow was corrupted
Did a hard refresh of my browser window where I’m editing on my workflow
Still, the same issue as observed before occured in a fresh execution.
I’m thinking this is a n8n cloud runtime bug. There are not commonalities with regards to the type, Inputs, or Settings among the issue-impacted nodes that explain this consistent “don’t produce Output” behavior.
The execution logs don’t even show the nodes where the issues are taking place, so there’s not even Trace to refer to.
I’m on n8n’s Starter Plan (cloud, not self-hosted), and version 2.28.5.
Hi @hazel Welcome!
In n8n a node only runs when it receives at least one item. When the connection feeding it delivers an empty array, the node is skipped entirely, no output, no error, and it never appears in the execution, which is why there’s no trace for it. Manual runs work because pinned data always supplies items, a live run has no such guarantee. The input you see on the node in the editor is the pinned or last-run data, not what the live execution actually delivered.
Open the failing live execution and check the real output count of the last node that did run before each silent one. That upstream node is emitting 0 items on that branch. If1 is the first place to look: with strict type validation, if billing.resultsReturned is missing or arrives as a string in live data, no item passes and everything after it simply doesn’t run.
Hi @Anshul_Namdev - thank you very much for your reply. The nodes are receiving Inputs in the live executions, and of the right data type, so I don’t think that is the issue. For example, I checked the If1 node and the upstream branch is emitting a structured JSON output with billing.resultsReturned as a number.
Any other ideas to why this may be happening? Can n8n check the logs of the live execution to troubleshoot?
Hey @hazel, since inputs and data types are confirmed correct, this looks like a cloud runtime issue. quick things to try:
Test with no other concurrent executions running, with concurrency set to 5, simultaneous runs can sometimes interfere with each other’s state.
Add an Error Trigger workflow, silent failures sometimes surface there even when the main execution log shows nothing.
Contact n8n support directly, since you’re on a cloud instance, they can pull raw server-side logs you can’t see. Highlight that affected nodes don’t appear in the execution trace at all, that’s the key detail that points to a platform-level issue.
@hazel looking at your image the Gmail node at the end has a red error icon on it, I suspect what has happened is the workflow has ran to that point and as that node has errored so it has stopped.
Can you check in your execution log to see if that node does have an error as that would explain the issue due to the node execution order.
@hazel Jon’s got it, that red icon on the Gmail node at the end is almost certainly the whole thing.
The piece worth understanding is that n8n doesn’t run everything on the canvas at once. It runs one branch all the way down before it starts the next, top branch first. So your top row runs right through to Create a draft, and if that Gmail node errors, the run just stops there by default. The lower branches never get their turn. That’s why those three nodes show no output, no error, and don’t even show up in the log. They didn’t fail, they never ran.
It’s also why manual testing is fine. When you pin data and run it by hand, every node already has data on it and gets executed directly, so nothing upstream stops it first.
The inputs looking correct is the part that trips everyone up. That input panel in the editor is pinned or last-run data, not what actually came through on the live run. If you want to know what If1 really got during the failed execution, open that specific run in the Executions tab and look there. My guess is it got nothing, because the run had already died on the Gmail node before it ever reached that far.
So it’s not concurrency and it’s not a cloud bug. The enterprise sandbox and the zeroed consumer id in your debug info are just normal cloud stuff.
Start by opening the failed run from the Executions tab and finding the one node that’s actually errored. Fix that, or if you want the rest to keep going regardless, open that node’s Settings tab and set On Error to Continue.
Honestly though, the bigger issue is that this is all one giant linear workflow. There’s way too much on a single canvas, and right now one Gmail hiccup quietly takes down the entire back half. I’d break this into two or three separate workflows. That plus an Error Trigger workflow will actually surface failures like this instead of hiding them.
Hi @hazel
On that Gmail node, set On Error to Continue (using error output) instead of Continue. Continue moves on using the last valid data with no signal anything happened, Continue (using error output) routes the failure to its own output so you can wire it to a Slack or email alert. That way a failure there stops silently killing the rest of the run, and you get pinged the moment it happens instead of chasing missing nodes after the fact.
