make.com Error Handling & Retry-Strategien: Robuste Szenarien bauen (2026)

Warum Error Handling in make.com kein Luxus ist

Ein Szenario, das im Test perfekt läuft, sagt nichts über Produktion aus. Sobald reale Daten fließen, treten genau die Edge Cases auf, die du nicht bedacht hast: Rate Limits, Timeouts, leere Felder, geänderte API-Responses, kurzzeitig nicht erreichbare Dienste.

Ohne Error Handling bricht das Szenario ab, der Bundle ist verloren, und der Fehler taucht erst auf, wenn jemand merkt, dass die Daten fehlen. Mit gutem Error Handling wird derselbe Fehler zur Routine: erkannt, behandelt, geloggt – und das Szenario läuft weiter.

Die vier Error-Handling-Directives in make.com

Wenn du in einem Modul auf "Add error handler" klickst, kannst du die nachgelagerte Route mit einem von vier Directives starten. Das Directive bestimmt, wie der Fehler verarbeitet wird:

1. Resume

Setzt das Szenario fort, als wäre der Fehler nie passiert. Du übergibst einen Ersatz-Bundle, der die nachfolgenden Module füttert.

Use Case: Ein optionales Enrichment via Clay schlägt fehl → du übergibst einen leeren Datensatz und das Lead kommt trotzdem ins CRM.

2. Rollback

Macht alle Transaktionen des aktuellen Bundles rückgängig (sofern das Modul Rollback unterstützt) und stoppt das Szenario.

Use Case: Du legst eine Bestellung in mehreren Systemen an. Schlägt ein System fehl, willst du keinen halb-erstellten Datensatz.

3. Commit

Bestätigt alle bisherigen Transaktionen und stoppt sauber. Das Szenario wird nicht als fehlerhaft markiert.

Use Case: Bewusster Abbruch bei einer Geschäftslogik-Bedingung (z. B. "Lead nicht qualifiziert").

4. Break

Speichert das Bundle in der Incomplete-Executions-Queue zur manuellen oder automatischen Wiederholung. Hier liegt der wichtigste Hebel für Retry-Strategien.

Retry-Strategien in der Praxis

Strategie 1: Break + Auto-Retry für transiente Fehler

Für Fehler, die typischerweise von selbst verschwinden (HTTP 429, 502, 503, Timeouts), nutze Break mit aktiviertem Auto-Retry:

Break Directive:
- Number of attempts: 3
- Interval: 15 minutes
- Allow storing: yes

Das Bundle wandert in die Incomplete Executions, make.com versucht es nach 15 Minuten erneut – bis zu drei Mal. Funktioniert es dann immer noch nicht, bleibt es liegen und wartet auf manuelle Aktion.

Strategie 2: Exponential Backoff via Sleep + Repeater

Für API-spezifische Rate Limits, bei denen feste Intervalle zu kurz sind:

Repeater (Initial value: 0, Step: 1, Repeats: 5)
  └── Sleep (delay = 2 ^ {{repeater.i}} seconds)
  └── HTTP Request
  └── Filter: status = 200 → exit loop

Wartet 1s, 2s, 4s, 8s, 16s zwischen Versuchen. Klassisches Pattern für externe APIs ohne natives Retry.

Strategie 3: Circuit Breaker via Data Store

Wenn ein Drittsystem nachweislich down ist, sind weitere Requests Verschwendung. Setze einen Circuit Breaker im Data Store:

1. Bei erstem Fehler: schreibe service_x_down = true mit TTL 10 Minuten
2. Vor jedem Request: prüfe Flag → bei true Skip oder Queue
3. Periodisches Health-Check-Szenario setzt Flag zurück, sobald der Service wieder antwortet

Spart Operations und verhindert kaskadierende Fehler in nachgelagerten Szenarien.

Strategie 4: Dead Letter Queue (DLQ)

Bundles, die nach allen Retries scheitern, gehören in eine zentrale Queue – idealerweise ein monday.com Board oder Google Sheet:

Error Route (Resume):
  └── monday.com → Create item in "Failed Executions" Board
       Felder: Scenario, Module, Error Message, Bundle JSON, Timestamp
  └── Slack → Notification an #automation-alerts

Jetzt hast du Sichtbarkeit, kannst Pattern erkennen und Bundles gezielt nachverarbeiten.

Best Practices für komplexe Szenarien

1. Error-Routen sind Pflicht, nicht Kür

Jeder Modul, der mit externen APIs spricht oder schreibende Operationen durchführt, braucht eine Error-Route. Punkt. Kein "das passiert schon nichts".

2. Fehler kategorisieren statt pauschal handhaben

Nicht jeder Fehler ist gleich. Filter auf error.message oder error.statusCode und routet:

• 4xx (außer 429): Daten-Problem → DLQ + Alert
• 429: Rate Limit → Backoff + Retry
• 5xx: Service-Problem → Circuit Breaker + Retry
• Timeout: Netzwerk → Retry mit längerem Timeout

3. Idempotenz sicherstellen

Bevor du Retry aktivierst: stelle sicher, dass dein Szenario idempotent ist. Ein Lead darf nicht doppelt erstellt werden, nur weil der Retry triggert. Lösungen: External-ID-Felder, Upsert-Logik, Dedup-Check vor Create.

4. Sub-Szenarien mit eigenem Error Handling

Lagere kritische Branches in Sub-Szenarien aus. Vorteile:

• Eigene Retry-Konfiguration pro Sub-Szenario
• Fehler im Sub-Szenario blockieren nicht das Parent-Szenario
• Bessere Beobachtbarkeit pro Funktionsblock

5. Breakpoints für Debugging

In komplexen Szenarien hilft Break als bewusster Stop-Punkt während der Entwicklung. Bundle landet in Incomplete Executions, du kannst es inspizieren und schrittweise weiterlaufen lassen.

6. Monitoring & Alerting nicht vergessen

Make.com bietet 2026 ein Enhanced Error Monitoring Dashboard mit Trend-Analyse. Konfiguriere zusätzlich:

• E-Mail-Notifications bei wiederholten Fehlern
• Slack-Webhook bei kritischen Szenarien
• Wöchentlicher Report: Top-5-Fehlerquellen pro Szenario

Wie du daraus einen kompletten Observability-Stack baust (native Dashboards + Better Stack Heartbeats + Datadog), zeigen wir im Monitoring & Observability Guide für make.com.

Anti-Patterns, die du vermeiden solltest

❌ Globaler Resume-Catch ohne Logging: Du unterdrückst Fehler still – das Szenario läuft "grün", die Daten sind aber kaputt.

❌ Endlose Retry-Loops ohne Limit: Eine fehlerhafte API mit unendlichem Retry frisst tausende Operations und blockiert den Worker.

❌ Error Handling erst nach Live-Vorfall: Der teuerste Zeitpunkt, eine Error-Route zu bauen, ist um 3 Uhr morgens nach dem ersten Major Incident.

❌ Identische Behandlung aller Fehler: Ein 401 (Auth) braucht andere Aktion als ein 503 (Service Down).

Praxis-Checkliste für jedes neue Szenario

• Jeder schreibende/externe Modul hat eine Error-Route
• Directive bewusst gewählt (Resume / Rollback / Commit / Break)
• Retry-Strategie definiert (Anzahl, Intervall, Backoff)
• Idempotenz geprüft (kein doppeltes Anlegen bei Retry)
• DLQ-Mechanismus für endgültig gescheiterte Bundles
• Alerting bei kritischen Fehlern
• Test-Cases für: Timeout, Rate Limit, leere Response, Auth-Fehler

Verwandte Guides

• make.com Automatisierung – Der ultimative Guide
• make.com vs. Zapier vs. n8n
• Make Module Migrator: monday.com V1 zu V2
• Monitoring & Observability für make.com
• Security & Secrets-Management in make.com
• n8n Best Practices Guide

Wir bauen produktionsreife Automatisierungen

Als make.com Certified Partner designen wir Szenarien, die nicht nur funktionieren, sondern auch unter Last, bei API-Ausfällen und mit unsauberen Eingangsdaten stabil bleiben. Inklusive Error-Handling-Architektur, Monitoring-Setup und Runbooks für dein Team.

→ Automatisierungs-Workshop buchen