what nobody tells you before you start with n8n

I've been running n8n builds for about two years now and there's a pattern to how people learn it - they hit the same walls in the same order most courses and tutorials teach you to think of n8n like a flowchart. trigger → node → node → result. clean, linear, logical but the moment you hit a real production workflow, flowchart thinking breaks down. because production workflows aren't linear. they're state machines. things run on schedules, wait for external events, branch based on data that arrives in different shapes, retry when services are down, and need to recover gracefully when something fails mid-execution here's what took me way too long to understand: 1. n8n is event-driven, not flow-driven the trigger isn't the start of a process - it's an event in a system that might already be in a state. a webhook firing doesn't mean "start here." it means "this thing happened, respond to it in whatever state you're in" 2. the canvas isn't the source of truth your workflow runs in memory on the n8n server. the canvas is just a visualisation. two workflows can look identical and behave completely differently based on how data actually flows at runtime 3. the debugging loop is the skill most people learn n8n by watching build tutorials. the actual skill - the one that separates someone who can maintain a workflow from someone who can build one that survives contact with real data - is learning to read execution history, pin test data, trace what each node actually received, and understand why a failure happened what took you the longest to actually understand about n8n? not a feature, the conceptual thing submitted by /a community member [link] [comments]