Automatyzacja padła w nocy na trzecim kroku. Dane z tej jednej sprawy albo gdzieś czekają, albo zniknęły

Scenariusz uruchomił się o 3:41. Pierwszy krok zapisał zamówienie w arkuszu, drugi wystawił fakturę w systemie sprzedaży, trzeci miał wysłać ją do klienta i zwrócił błąd limitu zapytań. O ósmej rano w arkuszu jest zamówienie, w systemie jest faktura, a klient nie ma nic.

Ta jedna sprawa jest teraz w jednym z trzech stanów: czeka w kolejce błędów na ręczne wznowienie, została już kilka razy ponowiona bez powodzenia i nikt nie dostał o tym powiadomienia, albo nie istnieje nigdzie poza wpisem w historii uruchomień. O tym, który stan zastaniesz, rozstrzygają dwa przełączniki, które ktoś musiał włączyć wcześniej — i to, czy funkcja ponawiania jest w ogóle dostępna w Twoim planie.

Zachowanie przy błędzie prawie nigdy nie trafia na stronę z cennikiem, więc dane poniżej pochodzą z dokumentacji producentów sprawdzonej 24 października 2026 roku. Porównane są cztery narzędzia, które realnie wchodzą w grę w małej firmie: Zapier, Make, n8n i Power Automate.

Co zostaje po przerwanym uruchomieniu, a co przepada?

Make ma na to osobny mechanizm: niedokończone uruchomienia (Incomplete executions), czyli kolejka, w której ląduje przerwany przebieg razem z danymi, które go wywołały. Rzecz w tym, że pomoc Make określa tę funkcję jako domyślnie wyłączoną — włącza się ją w ustawieniach scenariusza opcją przechowywania niedokończonych uruchomień. Dopóki tego nie zrobisz, scenariusz po błędzie po prostu się zatrzymuje. Dwa mechanizmy obsługi błędu, które pozwalają wrócić do sprawy później, też tego wymagają: dokumentacja mechanizmu Retry mówi wprost, że trzeba wcześniej włączyć niedokończone uruchomienia w ustawieniach scenariusza.

Zapier trzyma każde uruchomienie w historii Zapa, ale rozróżnia stany. Uruchomienia wstrzymane (on hold) są z automatycznego ponawiania wyłączone — pomoc Zapiera podaje, że autoreplay pomija uruchomienia ze statusem on hold i trzeba je wznowić ręcznie. To ważna różnica, bo wstrzymanie wygląda w panelu podobnie do błędu, a zachowuje się inaczej.

n8n i Power Automate nie mają kolejki błędów w tym sensie. Mają historię wykonań i mechanizm, który ma na błąd zareagować w momencie jego wystąpienia: w n8n to osobny przepływ obsługi błędu, w Power Automate — gałąź uruchamiana po nieudanej akcji. Jeśli nie zbudujesz ani jednego, ani drugiego, informacja o przerwanej sprawie zostaje w logu i czeka, aż ktoś tam zajrzy.

Czy narzędzie samo ponowi próbę i po jakim czasie?

Tu różnice są największe i najłatwiej je przeoczyć, bo wszystkie cztery narzędzia mówią o sobie, że „ponawiają próbę”.

Zapier ponawia krok, który padł, i robi to według stałego harmonogramu: pomoc producenta podaje do pięciu prób, pierwszą 5 minut po zdarzeniu, a kolejne po 30 minutach, godzinie, trzech i sześciu godzinach, czyli ostatnią około 10 godzin i 35 minut po pierwszym błędzie.

Make ponawia automatycznie tylko wybrane klasy błędów. Dokumentacja wymienia trzy: przekroczenie limitu zapytań, błąd połączenia i przekroczenie czasu modułu — a także te niedokończone uruchomienia, które powstały z mechanizmu Retry z włączonym automatycznym domykaniem przebiegu. Błąd danych albo nieważny token do tej listy nie należą i czekają na człowieka. Jeśli błąd się na liście znajdzie, harmonogram obejmuje osiem prób rozciągniętych na 7 godzin i 51 minut od pierwotnego uruchomienia, a na jeden scenariusz przypada limit trzech ponowień działających równolegle; nadwyżka czeka na swoją turę.

n8n odwraca logikę: ponawianie nie jest funkcją konta, tylko ustawieniem pojedynczego węzła. Dokumentacja opisuje w ustawieniach węzła przełącznik Retry On Fail, a obok niego liczbę prób i odstęp między nimi podawany w milisekundach. Dla limitów zapytań producent radzi ustawić odstęp większy niż limit — przy jednym zapytaniu na sekundę wartość 1000 milisekund. Konsekwencja jest praktyczna: domyślnie żaden węzeł nie ponawia niczego, dopóki tego nie włączysz, za to możesz ponawiać tylko ten jeden krok, który naprawdę jest nietrwały.

Power Automate działa podobnie, ale per akcja i z gotowymi politykami. Dokumentacja Microsoftu opisuje politykę ponawiania ustawianą w opcjach akcji, w odstępach stałych albo rosnących wykładniczo, z dwoma parametrami: odstępem początkowym i maksymalną liczbą prób, i zaleca wariant wykładniczy.

Czy ponawianie jest w Twoim planie?

W Zapierze to pytanie ma twardą odpowiedź: pomoc producenta wskazuje autoreplay jako dostępny w planach Professional, Team i Enterprise, a w planie darmowym jako niedostępny. Jeśli budujesz automatyzację obsługi zamówień na planie bezpłatnym, każda przerwana sprawa wymaga Twojej ręki. To jedna z niewielu sytuacji, w których dopłata kupuje nie wygodę, a ciągłość danych.

Dwa dodatkowe szczegóły z tej samej strony są łatwe do przegapienia. Autoreplay trzeba włączyć — nie działa sam z siebie. I działa w jedną stronę: wyłączenie go anuluje wszystkie zaplanowane przyszłe próby, nawet jeśli włączysz go ponownie przed następnym terminem. Przełączanie tej opcji w trakcie awarii potrafi więc skasować kolejkę, którą właśnie próbujesz ratować.

W Make bramką nie jest nazwa planu, lecz limit: pomoc podaje, że pułap przechowywanych niedokończonych uruchomień zależy od przydziału w ramach planu i obejmuje wszystkie scenariusze we wszystkich zespołach organizacji, a po jego przekroczeniu dostajesz komunikat o błędzie. Jedna zepsuta integracja produkująca błędy seriami potrafi więc zająć miejsce przeznaczone na wszystkie pozostałe.

W n8n i Power Automate ponawianie jest elementem budowy przepływu, nie funkcją taryfową — nie ma czego odblokowywać, jest co skonfigurować. Koszt jest przesunięty z abonamentu na czas osoby, która to poustawia węzeł po węźle.

Kiedy w ogóle dowiesz się, że coś padło?

Najdroższa różnica w całym zestawieniu nie dotyczy ponawiania, a ciszy, która mu towarzyszy. Zapier nie wysyła żadnych powiadomień o błędzie, dopóki nie zawiedzie ostatnia próba autoreplay. Przy harmonogramie rozciągniętym na ponad dziesięć godzin oznacza to, że awaria z 3:41 może odezwać się mailem po 14:00 — i to jest zachowanie zgodne z dokumentacją, nie usterka.

Ten sam schemat — proces wykonany, powiadomienie nie przyszło — zdarza się poza narzędziami do automatyzacji. W rozliczeniach ta cisza dotyczy pliku z fakturami odrzuconego przez rejestr, o czym nikt nie zawiadamia, a skutki są wymierne. Jeśli automatyzujesz krok, który wysyła dokument do zewnętrznego systemu, załóż, że brak komunikatu nie znaczy sukcesu.

W Make jest odwrotnie: niedokończone uruchomienie pojawia się w zakładce od razu, a ponawianie idzie w tle. Widzisz problem natychmiast, ale musisz tam zaglądać.

n8n daje najwięcej kontroli nad tym momentem, bo powiadomienie budujesz sam. Dokumentacja opisuje przepływ obsługi błędu wskazywany w ustawieniach przepływu, uruchamiany po nieudanym wykonaniu i rozpoczynający się węzłem Error Trigger, który dostaje dane wykonania: identyfikator, treść błędu, nazwę ostatniego wykonanego węzła i nazwę przepływu. Jeden taki przepływ może obsługiwać wiele innych, więc wystarczy zbudować go raz.

Power Automate rozwiązuje to przez kolejność: ustawienia „Run after” pozwalają wskazać, co ma się stać, gdy akcja zawiedzie, wygaśnie albo zostanie pominięta, a dokumentacja Microsoftu opisuje też wzorzec dwóch zakresów — jednego z logiką główną i drugiego uruchamianego, gdy pierwszy zawiedzie. Z punktu widzenia małej firmy jest to najbardziej pracochłonny z czterech modeli, ale też jedyny, w którym powiadomienie o błędzie jest zwykłym krokiem przepływu, a nie osobnym mechanizmem.

Czego ponowienie nie naprawi, a co zepsuje drugi raz?

Ponawianie jest bezpieczne tylko wtedy, gdy krok, który padł, można wykonać dwa razy bez skutków ubocznych. Zapytanie o dane — można. Wystawienie faktury, wysłanie wiadomości, pobranie płatności — nie można, a to właśnie te kroki padają najczęściej, bo sięgają do zewnętrznych usług z limitami.

Dwa udokumentowane zachowania robią tu najwięcej szkody. Pierwsze: w Make ponawiane jest nie samo nieudane wywołanie, a pozostała część przebiegu od miejsca błędu, przy czym mechanizm Retry wyciąga z przepływu wyłącznie wadliwą paczkę danych i zapisuje ją razem z komunikatem błędu, a reszta scenariusza leci dalej. Trzeba więc wiedzieć, które kroki za punktem awarii już się wykonały, zanim wznowisz sprawę ręcznie.

Drugie dotyczy rozgałęzień w Zapierze: pomoc producenta podaje, że kroki Filter i Paths nigdy nie są ponawiane, nawet gdy po wcześniejszym błędzie ich warunki wypadłyby inaczej. Wznowienie po kilku godzinach może więc przepchnąć sprawę ścieżką, która w tym momencie już nie jest właściwa — na przykład wysłać przypomnienie o płatności, która w międzyczasie wpłynęła.

Praktyczny wniosek jest niezależny od narzędzia: jeśli krok zmienia stan na zewnątrz, potrzebuje własnego zabezpieczenia przed podwójnym wykonaniem — sprawdzenia, czy dokument o tym numerze już istnieje, zanim powstanie drugi. Żadne z czterech narzędzi nie zrobi tego za Ciebie.

Kto to naprawia o czwartej nad ranem?

Automatyzacja bez obsługi błędu nie jest tańsza — ma tylko przesunięty koszt. Zamiast godzin na konfigurację płacisz godzinami na odtwarzanie, co się wykonało, a co nie, zwykle pod presją klienta, który czeka na dokument.

Jeśli utrzymujesz automatyzacje u klientów, to jest także pytanie o model rozliczeń: sprawdzanie kolejki błędów i wznawianie spraw to praca cykliczna, nie jednorazowe wdrożenie, i wyceniona jako jednorazowy projekt zwykle nie pokrywa kosztu. Temu przejściu z pracy projektowej na usługę rozliczaną cyklicznie poświęcony jest poradnik „Biznes na żądanie”, który omawia, jak taką usługę opisać i zamknąć w abonamencie.

Przy pracy na własnych procesach rachunek jest prostszy: wybierz jedno miejsce, w którym codziennie sprawdzasz kolejkę błędów, i wpisz to do rytmu tygodnia. Narzędzie, które powiadamia Cię po dziesięciu godzinach, wymaga tego bardziej niż takie, które pokazuje problem od razu.

Co sprawdzić przed podjęciem decyzji

• Czy ponawianie jest w Twoim planie, czy dopiero w wyższym — i czy ktoś je faktycznie włączył.
• Czy przerwana sprawa zachowuje dane wejściowe, czy tylko komunikat błędu w logu.
• Po jakim czasie dostaniesz pierwsze powiadomienie, licząc od momentu awarii, nie od ostatniej próby.
• Które klasy błędów narzędzie ponawia samo, a które z definicji czekają na człowieka.
• Czy ponawiany jest pojedynczy krok, czy reszta przebiegu za punktem awarii.
• Co się stanie z rozgałęzieniami przy wznowieniu po kilku godzinach.
• Jaki jest limit przechowywanych błędów i czy jest wspólny dla całej organizacji.
• Czy kroki wystawiające dokumenty i wysyłające wiadomości mają własne zabezpieczenie przed dublem.

Co z tego wybrać do swojego przypadku

Jeśli automatyzacja dotyka pieniędzy albo dokumentów i musisz wiedzieć o awarii w ciągu minut, a nie godzin, Zapier w planie darmowym odpada z powodu braku autoreplay, a Zapier w planie płatnym wymaga osobnego monitoringu, bo pierwszy mail przyjdzie dopiero po ostatniej próbie. Make nadaje się tu lepiej, pod warunkiem że od pierwszego dnia włączysz przechowywanie niedokończonych uruchomień i ustalisz, kto zagląda do tej zakładki.

Jeśli masz w zespole kogoś, kto skonfiguruje ponawianie węzeł po węźle i zbuduje jeden wspólny przepływ powiadomień, n8n daje najdokładniejszą kontrolę nad tym, co się ponawia i co słyszysz. Przy procesach opartych o Microsoft 365 ten sam efekt osiągniesz w Power Automate politykami ponawiania na akcjach i wzorcem dwóch zakresów, przy wyraźnie większym nakładzie pracy na starcie.

Decyzja do podjęcia jest jedna i nie dotyczy narzędzia: zanim włączysz pierwszy scenariusz na produkcji, zapisz, co ma się stać ze sprawą, która padnie w połowie, i kto się o tym dowie. Jeśli odpowiedź nie powstanie teraz, powstanie przy pierwszej awarii, pod presją i z niepełnymi danymi.