5 n8n Workflow Patterns I Use in Every Project

Published: (February 21, 2026 at 07:18 PM EST)
2 min read
Source: Dev.to

Source: Dev.to

Error Handler Sub-Workflow

Don’t scatter error handling across your main workflow. Create a dedicated error handler:

Main Workflow → On Error → Call Error Handler Sub-Workflow

The error handler should:

  • Log the full error context
  • Send alerts (Slack/email)
  • Store failed items for retry
  • Track error frequency

One place to manage all error logic.

Config Node at Start

Place a Set node with configuration as the first node in every workflow:

{
  "env": "production",
  "batchSize": 100,
  "retryAttempts": 3,
  "alertChannel": "#ops-alerts",
  "dryRun": false
}

Change behavior without editing the rest of the logic. Toggle dry‑run mode, adjust batch sizes, etc., all in one place.

Idempotency Checks

Before processing any item, verify whether it has already been handled:

// Check processed items table
const alreadyProcessed = await checkDatabase(item.id);
if (alreadyProcessed) {
  return []; // Skip
}

This prevents:

  • Duplicate emails
  • Double charges
  • Repeated API calls

Essential for workflows that might retry.

Batch + Delay Pattern

When hitting APIs with rate limits:

Split In Batches (10 items) → Process → Wait (1 second) → Loop

Simple but prevents most rate‑limit issues. Adjust batch size and delay based on the API’s limits.

Health Check Workflow

A separate workflow that monitors your other workflows:

  • Check execution history for failures
  • Verify expected runs happened
  • Test critical API connections
  • Alert if something’s off

Run it every hour to know about problems before users do.

Bonus: Logging Pattern

Every workflow should log:

  • Start time and trigger info
  • Items processed count
  • Any skipped items and why
  • Duration and outcome

Store logs in a simple database or even a Google Sheet. Invaluable for debugging.

Implementation Tips

Start simple. Don’t add all patterns to every workflow; introduce them as needed.

Use sub‑workflows. Error handlers, logging, and notifications should be reusable.

Document decisions. Add notes in n8n explaining why something works a certain way.

Version control. Export workflows regularly and keep them in Git.

The Result

Workflows that:

  • Handle failures gracefully
  • Are easy to debug
  • Don’t break under load
  • Can be modified safely

That’s the difference between a prototype and production.

More production patterns at

0 views
Back to Blog

Related posts

Read more »

Does anyone here us HCL DX?

!pichttps://media2.dev.to/dynamic/image/width=256,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farti...