N8N Error Handling: Retry, Fallback & Error Workflows voor Betrouwbare Automatisering

Een workflow die het doet als je test is mooi. Een workflow die het doet als een API down is, een server traag reageert, of data onverwacht leeg binnenkomt — dat is productie-klaar. In deze gids leer je hoe je n8n workflows bouwt die zichzelf herstellen, fouten afvangen en jou waarschuwen voordat het een probleem wordt.

Waarom Error Handling Cruciaal Is

De meeste n8n gebruikers bouwen workflows die werken op het "happy path" — als alles goed gaat. Maar in productie gaat geregeld iets mis:

Zonder error handling crasht je workflow stilletjes. Niemand merkt het — tot een klant vraagt waarom zijn bestelling niet verwerkt is.

Techniek 1: Retry on Fail

De eerste verdedigingslinie. Bijna elke node in n8n heeft een ingebouwde "Retry on Fail" instelling. Bij tijdelijke fouten (timeouts, 5xx errors) probeert de node het automatisch opnieuw.

Configuratie

Aanbevolen Instellingen per Situatie

Techniek 2: Error Output (Fouten Afvangen per Node)

Soms wil je dat een workflow doorgaat, ook als één node faalt. Denk aan: je stuurt 100 e-mails en bij 3 adressen faalt de verzending. Je wilt niet dat de hele workflow stopt.

Hoe het werkt

Elke node in n8n heeft twee uitgangen die je kunt activeren:

Instellen in n8n

// Voorbeeld: E-mails versturen met error handling

Google Sheets Read (100 contacten)
  ↓
Loop Over Items
  ↓
Email Node (verstuur mail)
  ├── ✅ Success → Google Sheets Update (status: "Verzonden")
  └── ❌ Error → Code Node (log fout) → Google Sheets Update (status: "Gefaald")
  ↓
Slack Node ("Resultaat: 97 verzonden, 3 gefaald")

Techniek 3: Error Workflow (Centraal Foutbeheer)

De Error Workflow is je vangnet. Als een workflow crasht — ondanks retry en error output — wordt automatisch een apart error workflow getriggerd. Handig voor monitoring en alerting.

Hoe je het instelt

Stap 1: Error Workflow Aanmaken

// Error Workflow (maak dit als apart workflow)

// Node 1: Error Trigger
// Dit is het startpunt. Het ontvangt automatisch:
// - execution.id (welke executie is gefaald)
// - workflow.id en workflow.name
// - execution.error (de foutmelding)
// - execution.lastNodeExecuted (welke node faalde)

// Node 2: Foutmelding formatteren
Code Node {
  const error = $json.execution.error;
  const workflow = $json.workflow;
  const lastNode = $json.execution.lastNodeExecuted;
  
  return {
    message: `❌ Workflow "${workflow.name}" is gecrasht!
    
Node: ${lastNode}
Fout: ${error.message}
Tijd: ${new Date().toLocaleString('nl-NL')}
    
Bekijk: https://n8n.jouwdomein.nl/workflow/${workflow.id}/executions`,
    severity: error.message.includes('timeout') ? 'warning' : 'critical'
  };
}

// Node 3: Slack Notificatie
Slack Node {
  Channel: "#automation-alerts"
  Message: {{ $json.message }}
}

// Node 4: (optioneel) Log naar database
PostgreSQL Node {
  Query: `INSERT INTO error_log (workflow, node, error, timestamp)
          VALUES ($1, $2, $3, NOW())`
}

Stap 2: Koppelen aan je Workflows

Ga naar je workflow → Settings (tandwiel rechtsonder) → selecteer bij "Error Workflow" het zojuist aangemaakte error workflow. Eén error workflow kan meerdere workflows bedienen.

Techniek 4: Fallback Strategieën

Een API die down is hoeft je workflow niet te blokkeren. Met fallback strategieën gebruik je een alternatieve route wanneer de primaire weg niet beschikbaar is.

Patroon: Primary/Fallback met Error Output

// Voorbeeld: OpenAI als primary, Claude als fallback

Trigger Node
  ↓
OpenAI Node (On Error: Continue Using Error Output)
  ├── ✅ Success → Gebruik OpenAI response
  └── ❌ Error → Claude/Anthropic Node (fallback)
                   ├── ✅ Success → Gebruik Claude response
                   └── ❌ Error → Standaard bericht teruggeven
  ↓
Merge Node (combineer resultaat van welke route dan ook)
  ↓
Volgende stap...

Patroon: Cached Data als Fallback

// API data ophalen met cache-fallback

// Stap 1: Probeer live data
HTTP Request (On Error: Continue Using Error Output)
  ├── ✅ → Code Node: sla data op in cache (bijv. Static Data)
  │        return { data: liveData, source: 'live' };
  │
  └── ❌ → Code Node: lees cached data
           const cached = $getWorkflowStaticData('global');
           if (cached.lastData) {
             return { data: cached.lastData, source: 'cache' };
           }
           throw new Error('Geen live data EN geen cache!');

// De workflow werkt altijd — ook als de API offline is.
// Je kunt zelfs een indicator toevoegen:
// "Gebaseerd op data van 2 uur geleden (API tijdelijk niet bereikbaar)"

Techniek 5: Custom Retry met Exponential Backoff

De ingebouwde retry gebruikt een vaste wachttijd. Bij API's met rate limiting is exponential backoff slimmer: elke retry wacht langer dan de vorige.

// Custom Exponential Backoff in Code Node

const maxRetries = 5;
const baseDelay = 1000;  // 1 seconde

let lastError = null;

for (let attempt = 1; attempt <= maxRetries; attempt++) {
  try {
    const response = await this.helpers.httpRequest({
      method: 'POST',
      url: 'https://api.example.com/data',
      body: { key: 'value' },
      headers: { 'Authorization': 'Bearer ' + $credentials.apiKey },
      timeout: 10000
    });
    
    // Succes! Return het resultaat
    return [{ json: { ...response, attempt, status: 'success' } }];
    
  } catch (error) {
    lastError = error;
    
    // Bereken wachttijd: 1s, 2s, 4s, 8s, 16s
    const delay = baseDelay * Math.pow(2, attempt - 1);
    // Voeg willekeurige jitter toe (voorkomt thundering herd)
    const jitter = Math.random() * delay * 0.2;
    
    if (attempt < maxRetries) {
      await new Promise(resolve => setTimeout(resolve, delay + jitter));
    }
  }
}

// Alle retries gefaald
return [{ json: {
  status: 'failed',
  error: lastError.message,
  attempts: maxRetries
}}];

Techniek 6: Dead Letter Queue (DLQ)

Sommige fouten zijn niet retryable — denk aan ongeldige data, verwijderde records, of permission errors. Voor deze gevallen bouw je een Dead Letter Queue: een plek waar gefaalde items worden verzameld voor handmatige review.

Main Workflow
  ↓
Node faalt (na alle retries)
  ↓
Error Output branch:
  ↓
HTTP Request → POST naar DLQ Workflow webhook
  Body: {
    "original_data": {{ $json }},
    "error": {{ $json.error.message }},
    "workflow": "Order Verwerking",
    "node": "Stripe Payment",
    "timestamp": "2026-03-10T14:30:00Z"
  }

// DLQ Workflow (apart workflow):
Webhook Trigger
  ↓
Google Sheets Append ("DLQ Log" sheet)
  ↓
Slack Alert (#dlq-review)
  "Nieuw item in DLQ: Order #{{orderId}} — {{error}}"

Techniek 7: Classificatie — Retryable vs. Niet-Retryable Fouten

Niet elke fout moet herhaald worden. Een 401 Unauthorized los je niet op door dezelfde request te herhalen. Bouw daarom een error classifier:

// Error Classifier in Code Node

const error = $json.error;
const statusCode = error.httpCode || error.statusCode || 0;

const classification = {
  // Retryable fouten (tijdelijk)
  retryable: [
    statusCode === 408,  // Request Timeout
    statusCode === 429,  // Too Many Requests (rate limit)
    statusCode === 500,  // Internal Server Error
    statusCode === 502,  // Bad Gateway
    statusCode === 503,  // Service Unavailable
    statusCode === 504,  // Gateway Timeout
    error.code === 'ECONNRESET',
    error.code === 'ETIMEDOUT'
  ].some(Boolean),
  
  // Niet-retryable fouten (data/permissie probleem)
  action: 'unknown'
};

if (classification.retryable) {
  classification.action = 'retry';
} else if (statusCode === 401 || statusCode === 403) {
  classification.action = 'refresh_credentials';
} else if (statusCode === 404) {
  classification.action = 'skip_item';
} else if (statusCode === 422) {
  classification.action = 'fix_data';
} else {
  classification.action = 'manual_review';
}

return { json: { ...error, classification } };

// Gebruik dit in een Switch node om elke categorie
// naar de juiste handler te sturen.

Monitoring Dashboard Bouwen

Error handling is pas compleet met monitoring. Hier is een minimale maar effectieve monitoring-opzet met n8n zelf.

Schedule Trigger (elke 15 minuten)
  ↓
n8n API (GET /executions?status=error&limit=50)
  ↓
Code Node (groepeer fouten per workflow)
  ↓
IF Node (nieuwe fouten sinds laatste check?)
  ├── Ja:
  │   → Slack Alert (samenvatting: 3 workflows gefaald)
  │   → Google Sheets Append (error log)
  └── Nee:
      → Niets doen (workflow eindigt)

Dagelijkse Health Report

// Dagelijkse samenvatting: elke ochtend om 08:00

Schedule Trigger (08:00, maandag-vrijdag)
→ n8n API: haal executies op van afgelopen 24 uur
→ Code Node {
  const executions = $json;
  const summary = {
    total: executions.length,
    success: executions.filter(e => e.status === 'success').length,
    failed: executions.filter(e => e.status === 'error').length,
    running: executions.filter(e => e.status === 'running').length,
    successRate: Math.round(
      (success / total) * 100
    ) + '%'
  };
  
  return {
    text: `📊 *Dagelijks Automation Report*
    
Totaal: ${summary.total} executies
✅ Geslaagd: ${summary.success}
❌ Gefaald: ${summary.failed}
⏳ Actief: ${summary.running}
📈 Success rate: ${summary.successRate}
    
${summary.failed > 0
  ? `⚠️ ${summary.failed} workflows hebben aandacht nodig!`
  : '🎉 Alles draait probleemloos!'}`
  };
}
→ Slack Node (#daily-report)

Best Practices Samenvatting

Conclusie: Bouw Workflows die Niet Breken

Error handling is het verschil tussen een demo en een productiesysteem. Begin met de basis (Retry on Fail + Error Workflow) en voeg geleidelijk geavanceerdere patronen toe naarmate je workflows complexer worden.

Gerelateerde Artikelen

• n8n Code Node: JavaScript & Python Custom Logic
• n8n Troubleshooting: Fouten Oplossen
• n8n Execution Modes: Queue & Worker Scaling
• n8n Slack Integratie voor Team Automatisering