Obsługa błędów w Make: jak sprawić, żeby scenariusz nie padał po cichu
Scenariusz w Make działał tygodniami, aż inFakt odpowiedział błędem przy jednej fakturze. Bez obsługi błędów Make cofnął wykonanie, a przy wyzwalaczu z webhooka od razu wyłączył cały scenariusz. Kolejne zamówienia nie dostały faktur, a alert trafił na skrzynkę, której nikt nie czytał. Pokazuję, jakie błędy zdarzają się w Make, którą z pięciu dyrektyw wybrać, jak ustawić niedokończone wykonania i alerty oraz jakie wzorce stosuję w scenariuszach z fakturami, wiadomościami i listami mailowymi.
Autor: Mateusz Matuszczak · Aktualizacja:
Jak ustawić obsługę błędów w Make?
Włącz przechowywanie niedokończonych wykonań, na kluczowych modułach dodaj ścieżkę błędu (prawy przycisk → Add error handler), wyślij z niej alert do konkretnej osoby i zakończ ją dyrektywą: Break dla błędów, które da się ponowić, Resume dla danych, które da się zastąpić, Ignore tylko tam, gdzie utrata jednego przypadku nic nie kosztuje.
🛠️ Zobacz instrukcję →Czym jest obsługa błędów w Make?
Każdy moduł może kiedyś zwrócić błąd. Pytanie brzmi, co wtedy zrobi scenariusz: zatrzyma się po cichu czy zareaguje tak, jak zaplanowałeś. Wybór platformy: Make vs Zapier vs n8n.
Obsługa błędów w Make to dodatkowa ścieżka (error handler route) podpięta pod moduł, która uruchamia się tylko wtedy, gdy ten moduł zwróci błąd. Na ścieżce można wysłać powiadomienie, zapisać dane do arkusza i zakończyć ją jedną z pięciu dyrektyw: Break, Resume, Ignore, Commit lub Rollback. Bez niej Make stosuje Rollback i po serii błędów wyłącza scenariusz.
Jakie błędy zdarzają się w Make?
Typ błędu widać w wyniku modułu jako Error: Type. Od niego zależy, czy ponowienie ma sens.
W skrócie: błędy dzielą się na chwilowe, które mijają same (połączenie, limit zapytań), i trwałe, które wymagają poprawki (złe dane, duplikat, wygasłe połączenie z kontem). Chwilowe warto ponawiać automatycznie. Trwałe trzeba zatrzymać, zgłosić człowiekowi i przetworzyć ponownie dopiero po naprawie.
| Typ błędu | Przykład z praktyki | Minie sam? | Co ustawić |
|---|---|---|---|
| ConnectionError | inFakt lub BaseLinker chwilowo nie odpowiada | Zwykle tak | Break z ponownymi próbami, np. 3 co 15 minut |
| RateLimitError | Za dużo zapytań do API naraz, np. przy masowym imporcie zamówień | Tak, po odczekaniu | Break z próbami; przy stałym problemie spowolnienie scenariusza |
| DataError | Brak NIP-u, pusty e-mail, zbyt długi adres, zła data | Nie | Alert + Break bez automatycznych prób albo Resume z wartością zastępczą; na przyszłość walidacja danych |
| DuplicateDataError | Kontakt lub dokument już istnieje w docelowym systemie | Nie | Zwykle Ignore lub Resume + zapis do logu, bo cel jest już osiągnięty |
| Błąd autoryzacji | Wygasły token, zmiana hasła, odłączone konto Meta lub Google | Nie | Alert do osoby z dostępem, ponowne połączenie konta, potem ponowienie wykonań |
Nazwy typów pochodzą z Make i pojawiają się w wyniku modułu. Pełna lista przyczyn awarii poza samym Make, np. limity planów czy zmiany zasad Meta, jest w artykule utrzymanie automatyzacji.
Break, Resume, Ignore, Commit czy Rollback: którą wybrać?
Dyrektywa stoi na końcu ścieżki błędu i decyduje, co stanie się z wykonaniem.
W skrócie: Break zapisuje przerwane wykonanie do ponowienia (automatycznie lub ręcznie) i jest najbezpieczniejszym wyborem dla procesów krytycznych. Resume podstawia wartość zastępczą i pozwala dokończyć scenariusz. Ignore porzuca błędny pakiet. Commit zatrzymuje scenariusz, zachowując to, co już zrobione. Rollback cofa zmiany i jest domyślny, gdy nie ustawisz niczego.
| Dyrektywa | Co robi | Status scenariusza | Kiedy używać |
|---|---|---|---|
| Break | Zapisuje resztę wykonania jako niedokończone; pozostałe pakiety idą dalej. Można ustawić liczbę prób i odstęp | Ostrzeżenie | Faktury, płatności, statusy zamówień, wiadomości do klienta |
| Resume | Zastępuje wynik modułu wartością, którą zdefiniujesz, i kontynuuje scenariusz | Sukces | Brakujące pole niekrytyczne, np. pusty telefon zastąpiony „brak” |
| Ignore | Odrzuca błędny pakiet; pozostałe są przetwarzane normalnie | Sukces | Duplikaty, raporty, zadania, w których utrata jednego przypadku nic nie kosztuje |
| Commit | Zatrzymuje wykonanie, zachowuje dotychczasowe zmiany, pomija resztę modułów | Sukces | Gdy dalsze kroki nie mają sensu, a to, co już zrobione, jest poprawne |
| Rollback | Zatrzymuje wykonanie i cofa zmiany w modułach obsługujących transakcje | Błąd | Rzadko celowo; to zachowanie domyślne bez obsługi błędów |
Ignore, Resume i Commit kończą się statusem „sukces”. Jeśli na ścieżce błędu nie ma alertu, w historii scenariusza wszystko wygląda dobrze, choć jeden przypadek przepadł. Dlatego przed każdą z tych dyrektyw dodaję moduł powiadomienia albo zapis do arkusza.
Jakie ustawienia scenariusza w Make sprawdzić?
Panel ustawień scenariusza (ikona koła zębatego w edytorze). Nazwy podaję tak, jak widać je w interfejsie.
W skrócie: włącz Store incomplete executions, żeby przerwane wykonania dało się ponowić, ustaw Errors before deactivation świadomie (pamiętając, że przy webhooku i tak liczy się pierwszy błąd), a Process data in order włącz tylko tam, gdzie kolejność ma znaczenie, np. przy zmianach statusów.
| Ustawienie | Co robi | Moja rekomendacja |
|---|---|---|
| Store incomplete executions | Przerwane wykonanie trafia do folderu niedokończonych zamiast wycofania | Włączone w każdym scenariuszu z fakturami, płatnościami i wiadomościami |
| Errors before deactivation | Ile błędów z rzędu dopuszczasz przed wyłączeniem scenariusza | Przy wyzwalaczu natychmiastowym ustawienie jest pomijane, scenariusz wyłącza się po pierwszym błędzie. Ratunkiem jest obsługa błędów na modułach |
| Process data in order | Wykonania idą po kolei, nowe czekają na rozwiązanie niedokończonych | Tylko gdy kolejność jest krytyczna. Jeden zablokowany przypadek wstrzyma wtedy wszystkie kolejne |
| Discard data if storage is full | Gdy folder niedokończonych jest pełny, dane z błędów są odrzucane bez możliwości odzyskania | Wyłączone dla procesów krytycznych; zamiast tego regularnie czyść folder |
| Commit after each module | Zatwierdza dane po każdym module zamiast na końcu scenariusza | Zostaw domyślne, chyba że wiesz, po co zmieniasz |
Dane niedokończonych wykonań liczą się do limitu przechowywania danych w Twoim planie Make. Raz w miesiącu sprawdź folder i usuń wykonania już obsłużone ręcznie.
Jak dodać obsługę błędów do scenariusza w Make? 6 kroków
Przykład: scenariusz, który po opłaceniu zamówienia w BaseLinkerze wystawia fakturę w inFakt i wysyła ją klientowi.
W skrócie: 1) włącz Store incomplete executions, 2) wskaż moduły krytyczne, 3) dodaj ścieżkę błędu z routerem po typie błędu, 4) wyślij alert do konkretnej osoby, 5) zakończ trasy właściwą dyrektywą, 6) przetestuj wymuszonym błędem.
-
1
Włącz przechowywanie niedokończonych wykonań
W ustawieniach scenariusza włącz Store incomplete executions. Bez tego dyrektywa Break nie ma gdzie zapisać przerwanego wykonania, a scenariusz po błędzie po prostu się cofa.→ To jedno kliknięcie, które pozwala później dogonić zaległe zamówienia. -
2
Wskaż moduły krytyczne
W przykładzie to moduł tworzący fakturę w inFakt i moduł wysyłki e-maila. Moduły pobierające dane (wyszukanie zamówienia) zwykle nie potrzebują osobnej ścieżki, bo ich błąd zatrzyma i tak dalsze kroki.→ Pytanie kontrolne: czy klient lub księgowość odczują, że ten moduł nie zadziałał? -
3
Dodaj ścieżkę błędu z routerem
Kliknij moduł prawym przyciskiem i wybierz Add error handler. Na ścieżce błędu dodaj router z filtrami poError: Type, np. osobna trasa dla ConnectionError i RateLimitError, osobna dla DataError, oraz trasa awaryjna bez filtra dla pozostałych błędów.→ Błąd, który nie pasuje do żadnej trasy, nie zostanie obsłużony. Trasa awaryjna jest obowiązkowa. -
4
Wyślij alert do konkretnej osoby
Na każdej trasie dodaj moduł e-mail, Slack lub Teams. W treści: nazwa scenariusza, nazwa modułu, typ i treść błędu, numer zamówienia, imię klienta. Dzięki temu osoba dyżurna od razu wie, czy obsłużyć przypadek ręcznie, zanim klient zapyta.→ Alert idzie do osoby wpisanej jako właściciel w rejestrze automatyzacji, nie na wspólną skrzynkę. -
5
Zakończ trasy właściwą dyrektywą
Błędy chwilowe: Break z automatycznymi próbami, np. 3 próby co 15 minut. Błędy danych: Break bez automatycznych prób, bo ponowienie złych danych da ten sam błąd, albo Resume, jeśli brakujące pole da się zastąpić. Trasa awaryjna: Break.→ Dyrektywa zawsze stoi na końcu trasy, po module alertu. -
6
Przetestuj wymuszonym błędem
Wyślij testowe zamówienie z danymi, które na pewno wywołają błąd, np. niepoprawnym NIP-em. Sprawdź trzy rzeczy: czy przyszedł alert, czy wykonanie trafiło do niedokończonych i czy scenariusz nadal jest włączony. Przy fakturach testuj na danych testowych, żeby dokument nie trafił do KSeF ( KSeF w małej firmie).→ Datę i wynik testu zapisz w rejestrze. Obsługa błędów, której nikt nie przetestował, to założenie, nie zabezpieczenie.
Jak bezpiecznie przetwarzać niedokończone wykonania?
Ponowienie to najprzyjemniejszy moment naprawy i najłatwiejszy, żeby coś zdublować.
W skrócie: Make automatycznie ponawia niedokończone wykonania z błędami chwilowymi, a dla pozostałych czeka na Ciebie. Zanim ponowisz wykonanie ręcznie, napraw przyczynę i sprawdź, w którym miejscu się zatrzymało. Wykonanie przerwane po wystawieniu faktury, a przed wysłaniem maila, po ponowieniu od początku wystawi drugą fakturę.
przyczyna
Najpierw naprawa
miejsce
Gdzie się zatrzymało
ochrona
Bez dubli
rejestr
Zapis
Jaką obsługę błędów ustawić w typowych scenariuszach?
Cztery rodzaje scenariuszy, które wdrażam najczęściej, i ustawienia, które się w nich sprawdzają.
Faktury i dokumenty
Zamówienia i statusy
Leady i listy mailowe
Wizyty i rezerwacje
* Linki partnerskie — jeśli założysz konto przez te linki, mogę otrzymać wynagrodzenie, a Twoje warunki się nie zmieniają. Polecam tylko narzędzia, które sam wdrażam i utrzymuję u klientów: narzędzia, które polecam.
Obsługa błędów w Make: co działa, a co nie?
Najczęstsze ustawienia, które widzę przy przeglądach cudzych scenariuszy.
Konsultacja: przegląd scenariuszy Make
Sprawdzę, co stanie się w Twoich scenariuszach przy błędzie, ustawię ścieżki błędów, alerty i ponawianie. Zobacz też jak pomagam w automatyzacji i systemach.
Najczęstsze pytania o obsługę błędów w Make
Dlaczego Make wyłączył mój scenariusz?
Czym różni się Break od Ignore w Make?
Co to są niedokończone wykonania w Make?
Czy Make sam ponawia scenariusz po błędzie?
Czy obsługa błędów zużywa operacje w Make?
Jak nie zdublować faktury przy ponownym przetworzeniu w Make?
Gdzie wysyłać alerty o błędach z Make?
Scenariusz → obsługa błędów → utrzymanie
Błąd się zdarzy. Ważne, kto się o nim dowie i co stanie się dalej.
Typy błędów, pięć dyrektyw, ustawienia scenariusza, instrukcja w 6 krokach, bezpieczne ponawianie i wzorce dla faktur, zamówień, leadów i wizyt. Chcesz, żebym przejrzał Twoje scenariusze? Umów konsultację.
Zakres przeglądu zależy od liczby scenariuszy i narzędzi.