Monitoring & Observability für make.com: Datadog, Better Stack & native Tools (2026)

Warum Make-Monitoring nicht optional ist

Ein make.com Szenario ist Infrastruktur, sobald ein anderes Team davon abhängt. Sobald Sales, Support oder Buchhaltung darauf zählt, dass der Workflow läuft, wird jeder unbemerkte Fehler zum Vertrauensschaden – egal wie elegant die Architektur ist.

Das Problem: Make selbst ist großzügig, aber zurückhaltend mit Alerts. Die Standard-Notifications reichen für ein, zwei aktive Szenarien. Sobald du in Produktion bist, brauchst du systematisches Monitoring – sonst merkst du Ausfälle erst, wenn sie schon Schaden gemacht haben.

Die drei Monitoring-Layer im Überblick

Layer	Tool	Was es zeigt	Setup-Aufwand
L1: Native	Make History, Notifications, Enhanced Error Monitoring	Welcher Run hat versagt, mit welchem Bundle	Niedrig
L2: Liveness	Better Stack Heartbeats, Cronitor, healthchecks.io	Läuft das Szenario überhaupt noch?	Mittel
L3: Observability	Datadog, Grafana, Logtail	Trends, SLA, korrelierte Logs über Tools hinweg	Hoch

Die Layer sind additiv: L2 ohne L1 ist blind, L3 ohne L1+L2 ist Overkill. Bau sie in dieser Reihenfolge auf.

Layer 1: Native Make Tools

Enhanced Error Monitoring Dashboard (2026)

Make hat 2026 das Enhanced Error Monitoring Dashboard ausgerollt. Das Ding ist ehrlich gut und wird oft übersehen. Es zeigt:

• Trend-Analyse pro Szenario (7 Tage, 30 Tage)
• Error-Rate als Prozentwert, nicht nur als Zähler
• Top-5 Fehlerquellen pro Szenario (Modul + Error-Type)
• Vergleich gegen Baseline ("um 340 % mehr Errors als sonst")

Für die meisten Teams ist das das einzige Dashboard, das sie morgens öffnen müssen. Pinne es dir an.

Notifications richtig konfigurieren

Standard-Notifications sind pro User und pro Szenario einstellbar. Sinnvolle Defaults:

• Bei Stop des Szenarios: immer aktiv (Mail + In-App)
• Bei "Incomplete Executions": aktiv, sobald du DLQ-Logik hast (sonst Spam)
• Bei "Operations limit reached": aktiv für Account-Owner

⚠️ Achtung Inbox-Spam: Ohne sauberes Error Handling werden Notifications schnell zu Rauschen. Lies dazu unseren Error Handling Guide.

Custom Webhook Notifications

Make kann pro Szenario einen Webhook bei Fehler abfeuern. Das ist die Brücke zu Layer 2 und 3:

Scenario Settings → Notifications → Webhook
URL: https://hooks.slack.com/services/... (oder Better Stack / Datadog)
Trigger: On error

Inhalt des Payloads ist customizable – nutze das für strukturierte Logs (JSON mit scenario_id, error_type, bundle_id, timestamp).

Layer 2: Better Stack Heartbeats

Native Notifications sagen dir, wenn etwas fehlschlägt. Sie sagen dir nicht, wenn etwas gar nicht erst läuft. Genau dafür sind Heartbeats da.

Das Konzept

Statt zu fragen "Hat das Szenario einen Fehler geworfen?", drehst du die Logik um: "Hat sich das Szenario in den letzten 5 Minuten gemeldet?"

Setup mit Better Stack

1. In Better Stack einen Heartbeat anlegen mit Erwartungs-Intervall (z.B. "alle 5 Min")
2. Better Stack gibt dir eine Heartbeat-URL: https://uptime.betterstack.com/api/v1/heartbeat/abc123
3. In deinem Make-Szenario am Ende ein HTTP-Modul GET https://uptime.betterstack.com/api/v1/heartbeat/abc123 anhängen
4. Solange der Run durchläuft, pingt er Better Stack
5. Bleibt der Ping aus → Better Stack alarmiert via Slack, SMS, Phone Call

Wann einsetzen?

• Polling-Szenarien: "Alle 15 Minuten Bestellungen aus Shopify ziehen"
• Cron-Szenarien: "Täglich um 03:00 Reports versenden"
• Kritische Webhook-Konsumenten: wo Stillstand teurer ist als sporadische Fehler

Anti-Pattern

❌ Heartbeat im Hauptpfad statt am Ende: Wenn das HTTP-Modul mittendrin sitzt und ein späteres Modul crasht, hat Better Stack trotzdem grünes Licht.

❌ Heartbeat im Error-Pfad: Lieber ein zweites HTTP-Modul, das einen separaten "Error-Heartbeat" pingt – oder besser direkt einen Datadog-Event.

Layer 3: Datadog (oder Grafana) für Observability

Wenn du in der Liga "mehrere Teams, mehrere Make-Accounts, kritische Geschäftsprozesse" spielst, brauchst du echte Observability. Datadog ist hier der Branchen-Standard, Grafana mit Loki + Prometheus die Open-Source-Variante.

Was du in Datadog korrelieren kannst

Make ist nur ein Modul in der Kette. Ein realer "Lead-to-Welcome-Mail"-Flow geht z.B. so:

Webform → Make → CRM-API → Email-Tool → Sendgrid

Wenn der Lead drei Stunden später noch keine Mail hat, willst du eine Timeline sehen, nicht fünf separate Dashboards. Datadog bietet das via:

• Make-Logs (über Webhook ins Datadog HTTP-Intake)
• CRM-Logs (HubSpot/Salesforce-Integration)
• Email-Logs (Sendgrid-Integration)
• Korrelations-ID im Bundle, die durch alle Systeme wandert

Setup-Pattern: Make → Datadog

Im Make-Szenario nach jedem kritischen Modul ein HTTP-Modul:

POST https://http-intake.logs.datadoghq.eu/api/v2/logs
Headers:
  DD-API-KEY: {{datadog_api_key}}
  Content-Type: application/json
Body:
{
  "ddsource": "make.com",
  "service": "lead-onboarding",
  "scenario_id": "{{scenario.id}}",
  "execution_id": "{{execution.id}}",
  "correlation_id": "{{1.correlation_id}}",
  "step": "crm_create",
  "status": "success",
  "duration_ms": 234,
  "message": "Lead created in HubSpot"
}

Damit baust du in Datadog Dashboards, Monitors und Anomaly Detection auf strukturierten Daten – keine Heuristik, keine Log-Regex.

Custom Metrics für SLA-Reporting

Sobald Logs strukturiert sind, kannst du in Datadog Metrics ableiten:

• make.scenario.runs.total – Anzahl Runs pro Szenario
• make.scenario.runs.failed – Anzahl Failures
• make.scenario.duration_ms – p50/p95/p99 Laufzeit
• make.scenario.operations – Operations pro Run

Daraus baust du ein SLA-Dashboard für die Geschäftsführung: "99,4 % Erfolgsquote über 30 Tage, p95-Laufzeit 12 Sekunden". Das ist die Sprache, die im Mgmt-Meeting funktioniert.

Alerting-Strategie: Severity-Stufen, nicht alles ist P0

Schlechtestes Anti-Pattern überhaupt: jeder Fehler wird ein Slack-Alert. Nach drei Tagen ignoriert das Team den Channel komplett.

Empfohlene Stufen

Stufe	Trigger	Kanal	Response-Zeit
P0	Szenario seit > 15 Min komplett aus	PagerDuty / SMS / Anruf	sofort
P1	Error-Rate > 5 % über 10 Min	Slack #alerts	< 30 Min
P2	Einzelne Fehler in unkritischem Szenario	Daily-Digest E-Mail	< 1 Tag
P3	Trend-Anomalien (z.B. "20 % mehr Operations als üblich")	Wöchentlicher Report	reaktiv

Konkrete Datadog-Monitor-Konfiguration

Monitor: Make Lead Onboarding Failure Rate
Type: Metric Monitor
Query: avg(last_10m):
  sum:make.scenario.runs.failed{service:lead-onboarding} /
  sum:make.scenario.runs.total{service:lead-onboarding} > 0.05
Notification:
  - if status = ALERT → @pagerduty-make-team
  - if status = WARN → @slack-make-alerts

Logs strukturieren statt parsen

Bau Logs von Anfang an als JSON, nicht als Freitext. Das spart später hunderte Stunden Regex-Pain.

Empfohlene Felder

{
  "timestamp": "2026-04-16T08:23:11Z",
  "scenario_id": "12345",
  "scenario_name": "lead-onboarding",
  "execution_id": "exec_abc123",
  "correlation_id": "lead_xyz789",
  "step": "crm_create",
  "status": "success",
  "duration_ms": 234,
  "operations_used": 3,
  "error_type": null,
  "error_message": null,
  "bundle_id": "bundle_456"
}

Mit correlation_id kannst du einen einzelnen Lead über alle Systeme verfolgen. Das ist Gold wert beim Debugging.

Praxis-Checkliste für Production-Monitoring

• Native Notifications für alle produktiven Szenarien aktiv
• Enhanced Error Monitoring Dashboard gepinnt
• Heartbeats für alle Polling-/Cron-Szenarien (Better Stack o.ä.)
• Strukturierte JSON-Logs an zentralen Sink (Datadog/Grafana)
• correlation_id läuft durch alle Bundles
• SLA-Dashboard mit p95-Laufzeit & Success-Rate pro Szenario
• Alerting in Severity-Stufen (P0–P3) sortiert
• Operations-Trend-Monitor (Anomaly Detection)
• Runbook pro P0-/P1-Alert verlinkt
• Quartalsweiser Review: welche Alerts sind Noise, welche fehlen?

Anti-Patterns auf einen Blick

❌ Nur native Notifications: Du siehst Fehler, aber nicht Stillstand.

❌ Alle Logs in eine E-Mail-Inbox: Wird ignoriert, bringt keine Trends.

❌ Heartbeats ohne Eskalation: Ein Heartbeat-Fail ohne Alert ist nur ein netter rotes Punkt im Dashboard.

❌ Jeder Error = P0: Alert-Fatigue garantiert.

❌ Logs ohne Korrelations-ID: Du wirst stundenlang Zeitstempel vergleichen.

❌ Kein Runbook: Wenn der Alert um 03:00 kommt, weiß niemand, was zu tun ist.

Verwandte Guides

• make.com Automatisierung – Der ultimative Guide
• Error Handling & Retry-Strategien
• Security & Secrets-Management in make.com
• Performance & Operations-Optimierung
• Make Module Migrator: monday.com V1 zu V2
• n8n Best Practices Guide

Wir bauen produktive Monitoring-Setups

Als make.com Certified Partner designen wir Observability-Stacks, die zu deinem Team und Budget passen – vom 3-Szenarien-Heartbeat-Setup bis zum Datadog-SLA-Dashboard für regulierte Branchen. Inklusive Runbooks und Onboarding für dein Ops-Team.

→ Monitoring-Workshop buchen