Make-Fehler überwachen.

Was Make selbst meldet

Make schickt bei einem Fehler, der einen Lauf abbricht, eine E-Mail, danach eine Sammelmail alle 5 Minuten, und eine weitere, wenn es ein Szenario abschaltet.¹ Abgeschaltet wird nach drei Fehlern in Folge, Szenarien mit sofortigem Trigger (Webhook) schon nach dem ersten.² Unvollständige Ausführungen, in denen die Fehlermeldung und die Daten des Laufs stehen, speichert Make nur, wenn du sie pro Szenario einschaltest.³

Das reicht für drei Szenarien. Bei dreißig, verteilt auf mehrere Teams und Kunden, gehen die Mails unter, und niemand sieht, dass derselbe Fehler seit einer Woche jede Nacht auftritt.

Was Fehlo daraus macht

• Ein Fehler pro Ursache. Fehlo gruppiert nach Szenario, Modul und Fehlerart. IDs, Zahlen, Links und E-Mail-Adressen in der Fehlermeldung zählen dabei nicht, damit ein Modul, das jedes Mal mit einer anderen Datensatz-ID scheitert, ein Fehler bleibt.
• Häufigkeit und Verlauf. Wie oft, seit wann, zuletzt wann, wie jeder andere Fehler in Fehlo.
• Direkt zum Lauf. Jeder Fehler verlinkt den gescheiterten Lauf und das Szenario in Make.
• Alarme, wie du sie willst: neue Fehler, Häufungen und zurückkehrende Fehler per E-Mail, Microsoft Teams, Discord, Google Chat, ntfy, Zulip oder Webhook.
• Neben deiner Software. Scheitert ein Szenario, weil deine API einen Fehler wirft, stehen beide Fehler in Fehlo.

Weg 1: über die Make-API (empfohlen)

Fehlo liest alle 5 Minuten die gescheiterten Läufe aller Szenarien einer Make-Organisation. An den Szenarien änderst du nichts.

1. Projekt in Fehlo anlegen und als Plattform „Make“ wählen.
2. API-Token in Make erstellen: Profil, Tab „API“, „Add token“. Gib ihm die Scopes scenarios:read, organizations:read, teams:read und dlqs:read.
3. Token in Fehlo einfügen. Fehlo findet die Zone deines Kontos (eu1, eu2, us1, us2) selbst. Erreicht der Token mehrere Organisationen, wählst du eine. Auf Wunsch beschränkst du die Überwachung auf einzelne Teams.
4. Testen: Lass ein Szenario scheitern und klick „Jetzt prüfen“, statt 5 Minuten zu warten.

Warum dlqs:read: Die Lauf-Protokolle von Make enthalten keinen Fehlertext. Den gibt es nur in den unvollständigen Ausführungen.⁴ Fehlo liest deshalb beides: die gescheiterten Läufe (GET /scenarios/{id}/logs mit Status Fehler) und die offenen unvollständigen Ausführungen (GET /dlqs).⁵ Ohne den Scope kommen die Läufe trotzdem an, aber ohne Meldung, und Fehlo zeigt dir einen Hinweis. Damit unvollständige Ausführungen entstehen, muss im Szenario „Store incomplete executions“ eingeschaltet sein.

Fehlo speichert den Token verschlüsselt und nutzt ihn nur lesend. Trennst du die Verbindung, löscht Fehlo ihn.

Weg 2: per Error-Handler

Ohne API-Token geht es über einen Error-Handler mit HTTP-Modul. Den richtest du in jedem Szenario einzeln ein:

1. Rechtsklick auf das Modul, das scheitern kann, dann „Add error handler“.
2. „HTTP“, „Make a request“: Methode POST, die Webhook-URL aus Fehlo, Body type „Raw“, Content type „JSON (application/json)“.
3. Diese Vorlage als Request content einfügen, MODULE durch den Modulnamen ersetzen und für TYPE und MESSAGE im Mapping-Panel Fehlertyp und Fehlermeldung aus dem Error-Bundle einsetzen:

{
  "scenario": { "id": "{{var.scenario.id}}", "name": "{{var.scenario.name}}" },
  "execution": { "id": "{{var.execution.id}}" },
  "module": { "name": "MODULE" },
  "error": { "type": "TYPE", "message": "MESSAGE" }
}

Die Webhook-URL antwortet immer mit 202, auch wenn Fehlo eine Meldung verwirft. So scheitert der Error-Handler selbst nie.

Grenzen und Kosten

Jeder gescheiterte Lauf zählt als ein Ereignis im Kontingent deines Plans; der Plan Free enthält 5.000 im Monat. Pro Make-Verbindung und Webhook-URL nimmt Fehlo höchstens 300 Fehler pro Stunde an. Beim ersten Abruf schaut Fehlo 24 Stunden zurück, danach nur auf neue Läufe. Verbinden und ändern können Admins, Manager und Inhaber. Läuft ein Szenario fehlerfrei, aber zu selten, hilft ein Heartbeat-Monitor: Das Szenario ruft am Ende eine URL auf, und Fehlo meldet sich, wenn der Aufruf ausbleibt.

Häufige Fragen