Curious about n8n, so I installed the Community Edition on a server. Downloaded what appeared to be a very popular workflow from the market and configured. When I tried to run it, it gets about 30% of the way through and then quits. I did get some of the final outputs, so the entire workflow does “kind of” work. Much to my dismay there is little to no visibility to what the actual error is/was that brought it to a halt. It appears that you have to be at the higher “paid” levels to view this secret error data easily. I find this marketing approach of yours concerning for several reasons. One, the simplest code I could probably write would be vanilla JavaScript. Even that can write detailed debugging info to the console. Whether you are developing with regular code in the language/framework of your choice, or low code like this, this platform is like a car where you have removed all of the critical instruments. You have no idea of what is going on. Which renders this generally non-functional or at the very least impractical to test/evaluate.
And unfortunately for you, that short circuits any meaningful evaluation I wanted to conduct for fitness regarding targeted use cases. I can’t tell if this platform would even be suitable as it breaks. And I can’t tell if it is breaking due to something obvious or something more concerning like a badly designed module for instance. It’s literally impossible to tell.
So, forcing new users to adopt the high paid level to find out why your community edition does not work is not a great upsell psychology. In fact, it has the opposite effect on me as an actual developer. I would rather code my own workflows in something like LangChain or CrewAI where I can see exactly what is going on rather than fumble around in the dark with this low code, opaque framework. If you want to upsell, upsell on features that add real value, don’t take the doors off the car rendering it a junker. All of your cars, from Community to Enterprise should have doors don’t you think. Bad call.
Evaluation is over. Not enough information available to determine fitness for any real purpose. So, the motivation to now upgrade/pay in order to have the privilege of debugging your platform/popular workflows is ZERO.
I’m sorry your workflows didn’t work correctly! I’ve never experienced such a problem on my self-hosted instance, and n8n works great for mine and many of my colleagues use-cases. Could you please let us know what environment you were running n8n in, what workflow you were running, and where the error occured? That way we can help fix your problem. If you wish to not use n8n, that’s okay too, as it sounds like you’re a developer who can utilize other tools to get your job done.
Thanks for the reply. The server is very powerful, lots of CPU, memory, storage, etc., that I test on. And n8n is running in Docker. The issue per my previous comments is that n8n has disabled/removed all detailed debugging features from Community server workflows. Low code is only useful if you can “low debug” it as well. LOL. This opaqueness as to the low-level execution(s) output negates in my opinion what looks like a pretty nice low code platform. You should be able to popup a console/log window and watch everything going on either during or after execution for ALL versions of this product. Removing that, “or not having that feature” makes this platform impractical. All coding platforms/languages, share, “or should” share this common basic prerequisite requirement. This is like trying to hammer a nail in with your eyes closed. Just dumb.
Can you share which workflow you tested and what broke, exactly? These are community contributed and not maintained by us, so I guess it’s possible they break at some point.
Scrape business emails from Google Maps without the use of any third party APIs
I can’t tell what broke exactly. I have no access to a contiguous, debugging log/output for this workflow. It looks like it may have broken in the loop/scrape emails from page area but it’s hard to tell exactly without a simple transaction/console log to look at. It you would output all errors to a console this would be super easy. I code all day in multiple languages. But you have Community crippled. And after wasting several hours trying to test it, our team gave up. Not a good investment in our time.
And BTW, I did look at the system logs but the messaging in there is not detailed with regards to what component, failed at what step/line. No real actionable info there either.
Which debug features are you referring to that are hidden behind a paywall? As far as I know there is one option which is debug in editor which copies the execution data to the workflow and is available in registered versions (which has no fee).
Unless you are referring to log streaming in which case that data can be found under /home/node/.n8n/n8nEvent.log but it may not show any extra meaningful data.
That is not our business model, nor is this something we would ever do.
You haven’t provided any way of reproducing so it’s impossible to say for sure, but if I had to bet I’d say that one of the nodes in the workflow returned no data, which means that the execution stops. That’s not a ‘secret error’, it’s the way n8n is designed to behave. When you open such a node it tells you this:
Sounds like we won’t be seeing you on the forums again, but if we do please assume positive intent before insinuating that we designed the Community edition to ‘not work’.
I did not say it was designed to “not work”. I said you can’t debug a workflow efficiently with the Community edition, because this version has no such capability. That was deliberate on your part. A “workflow platform” where you can’t efficiently troubleshoot a “workflow” seems very counterintuitive and counterproductive. The most valuable resource we spend every day is time, and when you are in the dark like this, you waste enormous amounts of time guessing.
This changed recently as I mentioned and if you register your instance which costs nothing you can access this feature however all this feature does is let’s you automatically copy the execution log data to the editor which can always be done manually as well so there really is nothing that is being missed.
The actual execution data you see is the exact same data you would see when you run the workflow from the UI, normally if a workflow stops mid flow it is because it has no data to work with but if it did error the node would have an error icon and would show a message.
To register your instance you can go to Settings > Usage and you will get a prompt about inserting your email address to unlock 3 extra features. The docs for what you get on community registered and how to enable it can be found here: Community edition features | n8n Docs
I fully understand that n8n is not for everyone at the moment and it can take a bit of time to get up and running but if you want to give it another go with the registered version it will at least hopefully clear up that there is no secret error data that is only available to paid plans and maybe we can help you get this workflow up and running with your data.
