What this means (non-technical) An IF node has two outputs: true and false. If only one branch is connected and the other is left unconnected, items sent to the unconnected branch are silently dropped. There is no automatic warning. What usually goes wrong If your condition does not match all items: Some items disappear. Processing becomes incomplete. Results appear inconsistent. Because there is no error, it may take time before anyone notices missing data. This often happen

What this means (non-technical) A Switch node routes items based on defined conditions. If an item does not match any condition and there is no fallback route, that item is dropped silently. No error. No warning. What usually goes wrong When upstream data changes: New values are introduced. Formats shift slightly. Unexpected edge cases appear. Items that don’t match existing routes simply disappear from the workflow. You may only discover the problem much later, when data cou

What this means (non-technical) This occurs when JSON.parse() is used in a Code node without handling possible errors. If the input string is not valid JSON, JSON.parse() throws an exception. This immediately crashes the workflow. What usually goes wrong APIs sometimes return: Error messages instead of JSON. Empty responses. Truncated or malformed data. When JSON.parse() encounters invalid input: The workflow stops entirely. All items being processed are lost. The error messa

What this means (non-technical) A merge deadlock occurs when a Merge node is configured to wait for multiple branches, but one branch never sends data. The Merge node keeps waiting forever. This usually happens when conditional logic prevents one branch from executing. What usually goes wrong If one branch produces no output: The Merge node never completes. The workflow appears “running” but makes no progress. No clear error is shown. Executions accumulate in a stuck state. T

What this means (non-technical) A fragile external call is an API request or external service call that has no retry or error-handling configuration. If the service fails once, the entire workflow fails immediately. There is no buffer for temporary issues. What usually goes wrong External services occasionally return errors due to: Short network interruptions. Temporary outages. Rate limiting. Timeouts. Without retry or controlled failure handling: The entire workflow stops.

What this means (non-technical) This happens when an HTTP Request node sits inside a loop and sends requests as fast as possible. For every item, the workflow immediately makes another external API call, without delay or rate control. If you have 1,500 items, that can mean 1,500 rapid-fire requests. What usually goes wrong External services often limit how many requests you can send per minute. Without throttling: You start receiving 429 “Too Many Requests” errors. Some reque

What this means (non-technical) This issue occurs when a workflow processes very large JSON responses. When n8n parses JSON, it loads the entire payload into memory. If the payload is very large, memory usage spikes. What usually goes wrong Large JSON payloads can: Slow down execution while parsing. Consume significant memory. Cause out-of-memory errors. Affect other workflows running at the same time. The crash may seem random, especially under high load. The workflow may wo

What this means (non-technical) Data pruning is the automatic deletion of old execution records. If pruning is not configured, n8n keeps all execution data forever. Over time, this creates unnecessary database growth. What usually goes wrong Without pruning: Execution history grows endlessly. The UI becomes slower to load. Backup sizes increase. Storage costs rise. Eventually, disk space can run out. This usually builds slowly, so it’s easy to ignore until performance drops n

What this means (non-technical) An indefinite wait occurs when a Wait node is configured to pause for an external event but has no timeout. If the expected event never happens, the workflow waits forever. What usually goes wrong When workflows wait indefinitely: Executions remain stuck in “waiting” state. Worker slots remain occupied. Execution history fills with incomplete runs. Business processes remain unfinished. It may look like the workflow is active, but it is actually

What this means (non-technical) A potential infinite loop occurs when a workflow repeats actions without a guaranteed stopping condition. This can happen in Split In Batches, Loop Over Items, recursive workflow calls, or inside Code nodes. If the loop never reaches an exit condition, it keeps running. What usually goes wrong When a loop doesn’t stop: CPU and memory usage increase. The workflow never completes. Other workflows may be blocked. The server can crash. The workflow

What this means (non-technical) Using SELECT * in a database query retrieves every column from a table. This includes fields you may not need, such as large text or JSON columns. It makes the workflow handle more data than necessary. What usually goes wrong When unnecessary columns are fetched: Memory usage increases. Network transfer time grows. Processing downstream nodes becomes slower. Changes to the database schema affect your workflow unexpectedly. If the table contains

What this means (non-technical) The N+1 problem occurs when you perform a database operation inside a loop. Instead of making one combined query, the workflow makes one query per item. If you have 5,000 items, that can mean 5,000 database calls. What usually goes wrong This leads to: Slow execution times due to repeated network calls. Increased load on the database. Connection limits being reached. Higher chance of partial failures. The workflow may work fine with small datas

What this means (non-technical) n8n can store execution data for every workflow run. If you save both successful and failed executions indefinitely, your database keeps growing. Over time, this creates “data bloat.” What usually goes wrong As execution history grows: The n8n interface becomes slower. Database storage increases continuously. Backups take longer. Disk space eventually fills up. At high workflow frequency, this can happen faster than expected. The system may slo

What this means (non-technical) This happens when you process items one by one instead of in groups. For example, using Split In Batches with a batch size of 1 means each item is handled separately, even if they could be processed together. It works, but it creates unnecessary overhead. What usually goes wrong When items are processed individually: Workflows take much longer to finish. APIs are called repeatedly instead of in bulk. Databases receive many small operations inst

What this means (non-technical) This happens when a premium AI model is used for tasks that don’t require advanced reasoning. Simple classification, formatting, or short summaries often do not need the most powerful model available. Yet the workflow may default to the most expensive option. What usually goes wrong Using a premium model unnecessarily: Increases cost per request. Slows down responses. Applies stricter rate limits. At small scale, this may not be noticeable. At

What this means (non-technical) If you do not set a maximum token limit for an AI node, the model can generate very long responses. The AI will continue generating until it reaches its internal limit or decides to stop. You are charged for all generated tokens. What usually goes wrong Without a limit: A short task may produce a very long response. Costs become unpredictable. Workflows take longer to finish. Large outputs may break downstream nodes expecting shorter text. This

What this means (non-technical) This occurs when you send large amounts of unnecessary data into an AI node. For example, passing an entire JSON response instead of only the specific fields the AI needs. AI providers charge based on tokens, which roughly reflect input and output size. What usually goes wrong When too much data is sent: Costs increase significantly. Responses take longer. Rate limits are consumed faster. The AI may produce less focused results because of irrel

What this means (non-technical) This happens when an AI node is placed inside a loop that processes one item at a time. For example, 50 items result in 50 separate AI API calls. Each call includes overhead and delay. What usually goes wrong Making one request per item: Increases latency significantly. Consumes API rate limits quickly. Raises costs due to per-request overhead. The workflow becomes slow and expensive. It may work fine with 5 items during testing, then struggle

What this means (non-technical) Aggressive polling happens when a trigger runs very frequently, often every few seconds. Instead of waiting for changes, the workflow repeatedly checks an external service for updates. This creates constant activity. What usually goes wrong If polling runs faster than the workflow, it can result in: Executions begin to stack up. The queue grows. The system slows down. External APIs may respond with rate limit errors because they are being calle

What this means (non-technical) In some setups, Code nodes may allow loading additional modules, depending on how the environment is configured. Some modules allow file system access, command execution, or network control. When these are imported inside workflows, they run with the same permissions as your n8n server. What usually goes wrong If unsafe modules are used: Code can read or modify server files. External connections can be opened. System commands can be executed. T