Describe the problem/error/question
For some reason, nodes that are pinned in my workflow are showing as “Pinned” in the execution tab even though the execution is not a test execution.
I have tried unpinning the node, however it still shows as “Pinned” in executions after the node has been unpinned and re-published.
What is the error message (if any)?
No error message.
Information on your n8n setup
- n8n version: 2.21.8
- Database (default: SQLite): default Cloud
- n8n EXECUTIONS_PROCESS setting (default: own, main): default
- Running n8n via (Docker, npm, n8n cloud, desktop app): n8n cloud
- Operating system: Windows 11, Helium Chromium browser
Hi @Evan711
It appears your n8n interface is showing a “Pinned” badge by mistake, which is likely a visual error rather than a problem with your actual workflow data. Even though you have unpinned the node, your browser or the n8n cloud service might be “remembering” the old setting due to a caching glitch. This means your workflow is likely running normally with real data, but the screen is incorrectly displaying the pinned status.
To fix this, you should first try a “hard refresh” of your browser (Ctrl+F5 or Cmd+Shift+R) to clear any stuck information. If that doesn’t work, try deleting the node and adding a fresh one to reset its settings. You can verify if the issue is just a visual bug by downloading your workflow as a JSON file; if the word “pinData” does not appear in that file, then your workflow is perfectly fine and the “Pinned” badge is simply a display error that you should report to n8n support help@n8n.io
@Evan711 the orange/yellow icon on “When Executed by Another Workflow” might not actually be the pinned-data indicator — it can also be n8n’s visual cue that the trigger received input data from a parent workflow’s Execute Workflow node. is the actual pinned content still showing up in the input/output panel of that node when u click into it, or just the icon thats reading pinned?
Welcome @Evan711 to our community! I’m Jay and I am a n8n verified creator.
Achamm’s instinct is right - the orange indicator on the “When Executed by Another Workflow” trigger node does not mean pinData is active. It’s n8n’s visual cue that the trigger received live data from a parent workflow’s Execute Workflow node. This is expected behavior for sub-workflows.
To confirm there’s no actual pinData left on the node, download your workflow as JSON and search for the string pinData inside the file. If it’s absent, the data in that node is 100% live data from the parent, not pinned - the badge is just the UI’s way of showing the node received input externally rather than firing on its own trigger. You can safely ignore it.
Posting here instead of opening a new issue because I’m pretty sure I’m seeing the same thing. I had an issue this morning where a webhook was triggered three times. When I look at the webhook node in n8n, it not only shows that the data is pinned, but it shows the pinned data on the output instead of the actual data that triggered the webhook. It’s definitely not showing the real execution data.
I’ve created two videos that show this in action. The first is a demonstration of the issue. The second is a demonstration of why this is a problem, where I have Baserow claiming it triggered the webhook once but n8n claiming it was triggered three times. This issue with pinned data showing up in the Executions tab makes it impossible to troubleshoot when the webhook data is still pinned in the Editor tab.
I opened an issue on GitHub for it, since I’m pretty sure this community is just copy/pasted AI-slop support theater from the blind leading the blind. I just wanted the OP to know he isn’t crazy and “hard-refresh your browser because it’s a visual glitch” or “it’s okay because it’s probably not real” can be dismissed as an answer.
Thanks Adrian! Your video demonstrates exactly the issue im running into. Glad to know I’m not crazy. Definitely an issue with n8n and not my browser.
I am facing the exact same issue and it is causing critical errors in our workflows.
Just like you mentioned, pinned nodes are now bleeding into production executions. This completely defeats the purpose of the feature, as we rely on pinned data solely to test flows in the editor without affecting the live, published workflow. Now, all our active webhooks/triggers are ignoring the real incoming data and using the pinned mock data instead.
This is a critical bug for anyone running n8n in production. Has anyone found a workaround to bypass this while we wait for an official fix from the n8n team?
I’m not seeing pinned data go into production execution. Only that the execution panel shows pinned data instead of the actual trigger data. If you have proof that your production workflows are running with pinned data, I would encourage you to make a video of that and attach it to the issue that I raised and linked to up above. Or open a new issue and put “critical” or “urgent” or something like that in the subject line so that somebody actually takes a look at it. If that’s genuinely happening, that’s a critical issue, and they will fix it immediately.
My issues was closed as a duplicate of an earlier issue which they say was a regression (fancy way of saying, “an unintentional bug that was introduced by a new feature and broke something that was already working,”) and will now be fixed in 2.22.6. They apologized for the inconvenience.
@adriandotgoins @Thiago_Domingues @Evan711 welcome to the n8n community.
new release on 01/06 with fixes.
Release notes | n8n Docs
@adriandotgoins
You are absolutely right. After doing some deeper testing based on your reply, I realized that the issue is indeed visual, just as you described.
The real incoming data is actually being processed correctly under the hood. However, the major aggravating factor here is that the execution panel completely masks this. It shows the workflow processing the pinned data, which means we completely lose the ability to inspect or access the real production data in the execution logs.
So, while it isn’t literally breaking the flow by sending mock data to production, it becomes a nightmare for debugging and monitoring, since we only have access to the visual results of the pinned data.
I’m really glad to hear they’ve acknowledged it as a regression and that a fix is already on the way for version 2.22.6. Thank you for pointing me in the right direction and clarifying the behavior!
The “Pinned” label in the execution log is a historical record; it shows what actually ran during that specific execution, not the current state of your workflow.
Any execution that triggered while the node was pinned will show Pinned permanently, even after you unpin. That part is expected and won’t change.
The question is whether new executions after unpinning + republishing are also showing Pinned. If they are, try a hard refresh (Ctrl+Shift+R) first; sometimes the browser serves a cached version of the workflow, and the unpin doesn’t actually reach the server. Then trigger a fresh execution and check that one specifically.
If new executions still show Pinned after the hard refresh, export the workflow JSON and search for a pinData key on that node. If it’s still there, the unpin didn’t persist; the save failed silently.
Delete it from the JSON, re-import, republish, and you should be clear.
Thank you for your thoroughness. The AI slop is making this gross
I made another post here: Pinned Node in execution view is annoying
