Flowpaja
Was Sie benötigen
- Zugriff auf das Szenario in Make.com, mit Bearbeitungsrechten
- Zugriff auf die Nutzungs- und Verbindungsseiten der Organisation
- Die Benachrichtigungs-E-Mails, die Make an den Kontoinhaber schickt, sofern noch vorhanden
Schritt für Schritt: die Ursache finden
1. Schalter und Zeitplan prüfen
Öffnen Sie das Szenario. Steht der ON/OFF-Schalter auf ON? Sehen Sie danach unten auf die Zeitplan-Einstellung. Ist das Szenario auf „on demand“ gestellt oder der Zeitplan ausgeschaltet, startet es nie von selbst. Duplizierte oder importierte Szenarien kommen oft inaktiv oder mit ausgeschaltetem Zeitplan an, daher ist die „neue“ Kopie, die nie läuft, ein häufiger Fall.
2. Den History-Tab öffnen
Jeder Lauf steht dort mit seinem Status. Suchen Sie den letzten erfolgreichen Lauf und den ersten Fehler danach. Klicken Sie den fehlgeschlagenen Lauf an und suchen Sie das Modul mit der roten Markierung. Die Fehlermeldung dort ist meist schon die ganze Antwort. Gibt es ab einem bestimmten Zeitpunkt gar keine Läufe mehr, liegt die Ursache nicht in einem Modul: Prüfen Sie Zeitplan, Deaktivierung und Credits.
3. Prüfen, ob Make das Szenario deaktiviert hat
Make schaltet ein Szenario aus, wenn es mehrere Läufe hintereinander mit einem Fehler endet. Die Zahl legen Sie in den Szenario-Einstellungen fest (Number of consecutive errors, in neueren Versionen Errors before deactivation); laut Make-Hilfe ist der Standardwert 3. Manche Fälle überspringen die Zählung: Ein Szenario mit einem Instant-Trigger, etwa einem Webhook, wird schon nach dem ersten Fehler deaktiviert, und schwere Fehler wie AccountValidationError, OperationsLimitExceededError und DataSizeLimitExceededError schalten den Zeitplan sofort ab. Läufe, die mit einer Warnung enden, zählen nicht. Der Kontoinhaber erhält in der Regel eine E-Mail dazu. Beheben Sie zuerst die Fehlerursache und schalten Sie das Szenario danach ein. Wenn Sie es nur einschalten, schlägt es wieder fehl und stoppt erneut.
4. Incomplete Executions ansehen
Öffnen Sie den Tab Incomplete executions des Szenarios. Läufe, die fehlgeschlagen sind, während in den Szenario-Einstellungen Store incomplete executions aktiviert ist, oder die auf einen Retry-Error-Handler (früher Break) gestoßen sind, warten dort. Gespeicherte Incomplete Executions zählen zum Speicherkontingent Ihres Tarifs. Sie können jeden Eintrag öffnen, den Fehler ansehen, das Problem beheben und den Lauf wiederholen oder löschen. Das ist aus zwei Gründen wichtig: Ungelöste Einträge können sich unbemerkt ansammeln, und ist Process data in order (sequenzielle Verarbeitung) aktiviert, pausiert Make neue Läufe, bis alle Incomplete Executions erledigt sind. Kommen neue Daten an, aber nichts wird verarbeitet, schauen Sie in diesen Tab.
5. Verbindungen prüfen
Öffnen Sie in Make die Seite Connections und suchen Sie nach einer Warnung bei einer Verbindung, die das Szenario nutzt. Google-Verbindungen laufen ab, wenn Sie Ihr Google-Passwort ändern, der Zugriff widerrufen wird oder Sie eine eigene Google-OAuth-App verwenden, die noch den Status „Testing“ hat (Google kann solche Tokens nach etwa einer Woche ablaufen lassen). Autorisieren Sie die Verbindung neu und führen Sie das Szenario danach einmal manuell aus.
6. Credits prüfen
Make zählt die Nutzung in Credits (ältere Tarife und Dokumente sprechen von Operationen). Im Dashboard oder auf der Nutzungsseite der Organisation sehen Sie, wie viel vom Monatskontingent verbraucht ist. Sind die Credits aufgebraucht, schlagen Module mit OperationsLimitExceededError fehl, und Make schaltet den Zeitplan des Szenarios sofort ab. Prüfen Sie nach der Erneuerung oder einem Nachkauf, ob das Szenario wieder eingeschaltet ist. Ist es zu früh aufgebraucht, öffnen Sie die History Ihrer aktivsten Szenarien und suchen eines, das jede Minute auf einen Trigger läuft, der selten Daten hat.
7. Data-Store-Limits prüfen
Öffnen Sie die Seite Data stores. Jeder Store hat eine Größe, und Ihr Tarif hat ein Gesamtlimit für den Speicher. Ist er voll, schlagen Schreibvorgänge mit einem Fehler fehl, und das kann die Abschaltung nach aufeinanderfolgenden Fehlern aus Schritt 3 auslösen. Löschen Sie alte Datensätze, bauen Sie einen Aufräumschritt ein, der Datensätze nach einer bestimmten Zeit entfernt, oder erhöhen Sie das Speicherkontingent.
8. Warnungen einrichten, damit Sie es zuerst erfahren
Fügen Sie bei wichtigen Szenarien an dem riskanten Modul eine Error-Handler-Route hinzu, die Ihnen eine E-Mail oder Slack-Nachricht mit Szenarionamen und Fehlertext schickt. Der stille Fehler ist der teure.
Häufige Fehler und Lösungen
„Token has been expired or revoked“ oder ein 401 von Google. Die Verbindung hat ihre Autorisierung verloren. Autorisieren Sie sie unter Connections neu. Passiert das jede Woche, nutzen Sie vermutlich eine eigene Google-App im Status Testing. Veröffentlichen Sie die App oder verwenden Sie die Standardverbindung von Make, wenn Ihr Anwendungsfall das zulässt.
OperationsLimitExceededError: Credit-Limit erreicht. Make behandelt das als schweren Fehler und schaltet den Zeitplan sofort ab, ohne die Zählung aufeinanderfolgender Fehler abzuwarten. Kaufen Sie Credits nach, wechseln Sie den Tarif oder warten Sie auf die Erneuerung und schalten Sie das Szenario dann wieder ein. Suchen Sie außerdem das Szenario, das alles verbraucht hat: Ein Zeitplan im Minutentakt auf einem Watch-Trigger, der nichts findet, kostet trotzdem bei jeder Abfrage einen Credit. Oft genügt es, die Häufigkeit zu senken.
Ein Data-Store-Fehler, der Speicher oder Größe erwähnt. Der Store oder Ihr Gesamtspeicher ist voll. Löschen Sie zuerst Datensätze und aktivieren Sie das Szenario danach. Prüfen Sie die aktuellen Limits Ihres Tarifs.
Das Szenario hat sich nach wiederholten Fehlern selbst ausgeschaltet. Ein fehlerhaftes Modul, oft eine Verbindung oder ein geändertes Feld in der Quelltabelle, hat mehrere Fehler hintereinander erzeugt. Die Einstellung für aufeinanderfolgende Fehler hat getan, wofür sie gedacht ist. Beheben Sie die Ursache, führen Sie einmal manuell aus und bestätigen Sie den Erfolg, bevor Sie aktivieren.
Neue Daten kommen an, aber nichts läuft, und es gibt keine Fehler. Prüfen Sie Incomplete Executions, wenn Process data in order aktiviert ist, und kontrollieren Sie, ob Webhook oder Trigger noch auf das aktive Szenario zeigen. Ein dupliziertes Szenario hat unter Umständen eine neue Webhook-URL.
Läufe laufen in ein Timeout oder enden mit „scenario execution time exceeded“. Ein einzelner Lauf hat länger gedauert als das Limit Ihres Tarifs. Verringern Sie die Zahl der Elemente pro Lauf oder teilen Sie die Arbeit auf zwei Szenarien auf. Das genaue Limit hängt vom Tarif ab; prüfen Sie die aktuelle Make-Dokumentation.