What this means (non-technical) Execution progress saving stores intermediate steps while a workflow is running. This stores intermediate state during execution, which can affect how workflow interruptions are handled depending on configuration, but it also increases database writes during execution. It adds overhead to every run. What usually goes wrong When enabled on high-frequency workflows: Database load increases. Execution speed decreases slightly. Storage usage grows

What this means (non-technical) If a workflow has no execution timeout configured, it can run indefinitely. If something gets stuck, there is nothing to automatically stop it. These long-running executions continue consuming resources. What usually goes wrong Without timeouts: Stuck executions remain active forever. Memory and CPU usage increase. Worker slots stay occupied. Other workflows are delayed. The workflow may look “running,” but it is actually frozen. Over time, the

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