n8n Limit Node: Control How Many Items Flow Through Your Workflow
The Limit node is one of the simplest nodes in n8n, but it solves a very specific and common problem: controlling exactly how many items continue through your workflow. Sometimes you only want to process the first 10 results from an API, cap a batch at 100 records, or take just the top result from a sorted list. The Limit node handles all of these in a single configuration without any custom code.
In this guide we cover what the Limit node does, its two modes, and the practical scenarios where it belongs in your workflows.
What the Limit Node Does
The Limit node receives any number of items from the previous node and passes only a specified number through to the next node. Items beyond the limit are dropped — they don’t go anywhere and don’t trigger downstream nodes. The Limit node doesn’t modify any item data; it only controls quantity.
It has exactly two settings: the Max Items count (how many items to keep), and which items to keep — either the items from the beginning of the list (the first N items) or from the end of the list (the last N items). That’s it. Simple, focused, and very useful in the right context.
Keep From Beginning
The default mode — Keep From Beginning — passes through the first N items and discards the rest. This is the most commonly used configuration. It’s useful when you’ve already sorted your data in priority order and just want the top results.
For example: fetch all open support tickets sorted by age (oldest first), then Limit to 20 to process only the most overdue tickets in each workflow run. Or fetch all products from an e-commerce API, sort by sales rank, then Limit to 5 to build a “Top 5 Products” section in a report. The Limit node ensures downstream nodes only see exactly the items you want, regardless of how many came in.
Keep From End
Keep From End does the opposite — it discards the first items and keeps the last N. This is useful when your data arrives in chronological order and you want the most recent records, or when your sorting puts the highest-priority items at the end of the list.
For example: a node that returns log entries in chronological order — Limit with Keep From End grabs the most recent entries without needing to reverse the list first. Or after sorting a list of candidates from lowest to highest score, Limit from End gives you the top scorers efficiently. Keep From End is essentially a “tail” operation on your item array.
Common Use Cases
The Limit node appears in several recurring workflow patterns. In top-N reporting: sort items by a metric, then Limit to get the top performers for a report or alert — top 10 customers by revenue, top 5 slowest API endpoints, top 3 candidates by score. In API rate management: when you know processing each item triggers an expensive API call, Limit the items before the HTTP Request node to stay within rate limits or budget constraints per execution.
In sampling and testing: during development, use a Limit node after your trigger to process only 1-5 items from a large dataset while you’re testing logic — then remove or increase the Limit when you’re ready for production. In first-match extraction: after a filter that might return multiple matches, Limit to 1 to grab only the first (most relevant) result when you only need one record to continue the workflow.
Limit vs. Other Approaches
You could achieve similar behavior with a Code node using JavaScript’s .slice() method, or with an IF node and a counter variable — but the Limit node is cleaner, more readable, and requires zero code. It also makes your workflow self-documenting: any collaborator looking at the workflow immediately understands that a cap is in place and what it is.
The Limit node is also more maintainable than code-based approaches because the count is a plain, editable number in the node UI rather than something buried inside a script. When requirements change and you need to increase the cap from 10 to 50, it’s a one-field update in the Limit node.
Combining Limit with Other Nodes
Limit is most powerful when combined with Sort and Filter. The typical pattern is: Filter to remove items you definitely don’t want, Sort to put the best candidates first, then Limit to take only the top N. This three-node sequence replaces what would otherwise be a custom Code node with sorting and slicing logic.
Another useful combination is Limit followed by Split In Batches for controlled batch processing — Limit caps the total volume, and Split In Batches then processes them in smaller chunks to avoid overwhelming downstream APIs or systems. You can also use multiple Limit nodes in a workflow when different branches need different item caps.
