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 ? It will become hidden in your post, but will still be visible via the comment's permalink. as well , this person and/or CODE_BLOCK: Main Workflow → On Error → Call Error Handler Sub-Workflow 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 } 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 } 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 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