Tools: 5 n8n Workflow Patterns I Use in Every Project

1. Error Handler Sub-Workflow ## 2. Config Node at Start ## 3. Idempotency Checks ## 4. Batch + Delay Pattern ## 5. Health Check Workflow ## Bonus: Logging Pattern ## Implementation Tips ## The Result After building hundreds of n8n workflows, certain patterns keep proving their worth. Here are five I now use in almost every project. Don't scatter error handling across your main workflow. Create a dedicated error handler: One place to manage all error logic. First node in every workflow: a Set node with configuration. Change behavior without editing logic. Toggle dry-run mode. Adjust batch sizes. All in one place. Before processing any item, check if it's already been handled: Essential for workflows that might retry. When hitting APIs with rate limits: Simple but prevents 90% of rate limit issues. Adjust batch size and delay based on the API's limits. Separate workflow that monitors your other workflows: Run it every hour. Know about problems before users do. Every workflow should log: Store in a simple database or even a Google Sheet. Invaluable for debugging. Start simple. Don't add all patterns to every workflow. Add them as you need them. Use sub-workflows. Error handlers, logging, and notifications should be reusable. Document decisions. Sticky notes in n8n explaining WHY something works a certain way. Version control. Export workflows regularly. Use git. That's the difference between a prototype and production. More production patterns at mardenseo.com/n8n/tutorials Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: Main Workflow → On Error → Call Error Handler Sub-Workflow Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Main Workflow → On Error → Call Error Handler Sub-Workflow CODE_BLOCK: Main Workflow → On Error → Call Error Handler Sub-Workflow CODE_BLOCK: { "env": "production", "batchSize": 100, "retryAttempts": 3, "alertChannel": "#ops-alerts", "dryRun": false } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: { "env": "production", "batchSize": 100, "retryAttempts": 3, "alertChannel": "#ops-alerts", "dryRun": false } CODE_BLOCK: { "env": "production", "batchSize": 100, "retryAttempts": 3, "alertChannel": "#ops-alerts", "dryRun": false } CODE_BLOCK: // Check processed items table const alreadyProcessed = await checkDatabase(item.id); if (alreadyProcessed) { return []; // Skip } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: // Check processed items table const alreadyProcessed = await checkDatabase(item.id); if (alreadyProcessed) { return []; // Skip } CODE_BLOCK: // Check processed items table const alreadyProcessed = await checkDatabase(item.id); if (alreadyProcessed) { return []; // Skip } CODE_BLOCK: Split In Batches (10 items) → Process → Wait (1 second) → Loop Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: Split In Batches (10 items) → Process → Wait (1 second) → Loop CODE_BLOCK: Split In Batches (10 items) → Process → Wait (1 second) → Loop - Logs the full error context - Sends alerts (Slack/email) - Stores failed items for retry - Tracks error frequency - Duplicate emails - Double charges - Repeated API calls - Check execution history for failures - Verify expected runs happened - Test critical API connections - Alert if something's off - Start time and trigger info - Items processed count - Any skipped items and why - Duration and outcome - Handle failures gracefully - Are easy to debug - Don't break under load - Can be modified safely