Poniedziałek rano. Klientka pisze, że od jakiegoś czasu nie dostaje maili z potwierdzeniem zamówienia, i pyta, czy w ogóle jeszcze działacie. Otwierasz panel automatyzacji. Scenariusz, który zbudowałeś zeszłej jesieni i o którym zdążyłeś zapomnieć, bo po prostu chodził, jest wyłączony. Nie przez Ciebie. W historii widać serię błędów autoryzacji, potem ciszę, a potem już nic, bo historia z tamtych dni zdążyła się wyczyścić.
W samym scenariuszu nic się nie zepsuło. Zmieniło się coś po drugiej stronie.
Brzmi znajomo? Tak wygląda koszt utrzymania automatyzacji, czyli wszystko, co płacisz już po wdrożeniu: czas, zanim ktoś zauważy awarię, czas na znalezienie przyczyny, naprawę i aktualizacje, których nikt nie zamawiał, a które przychodzą same. Porównania narzędzi go pomijają, bo zestawiają funkcje i ceny, czyli rzeczy widoczne w dniu zakupu. Po roku ta druga część potrafi przerosnąć pierwszą.
Te zmiany po drugiej stronie nie są rzadkie. Make w lipcu 2026 oznaczył jako przestarzałe większość modułów Bitbucketa, powołując się na zmiany w API Atlassiana. n8n pisze w dokumentacji, że nową wersję wydaje w większość tygodni. Każdy taki komunikat oznacza, że ktoś musi usiąść i sprawdzić swoje scenariusze.
O tym, jak te trzy narzędzia liczą wykonania i co mówi licencja n8n, pisałem we wpisie czym jest n8n i kiedy ma sens zamiast Make albo Zapiera. Tamten tekst odpowiada na pytanie, ile zapłacisz dostawcy. Ten liczy, ile zapłacisz sobie: kto pilnuje scenariuszy, gdy już działają, i ile tej roboty każde z narzędzi zostawia po Twojej stronie.
Scenariusz psuje się po cudzej stronie
Automatyzacja to łańcuch połączeń z usługami, których nie kontrolujesz. Twój scenariusz może być zbudowany bez zarzutu i nadal przestać działać, bo zmieniła się jedna z trzech rzeczy: interfejs usługi, uprawnienia połączenia albo dane, które do niego wpadają.
📖 Ze słownika Noraline API — interfejs, przez który jeden system rozmawia z drugim według ustalonych reguł: jakie pytanie wolno zadać, w jakim formacie przyjdzie odpowiedź i kto ma prawo pytać. Każda integracja w Make, Zapierze czy n8n jest nakładką na czyjeś API. Kiedy właściciel zmienia reguły, nakładka przestaje pasować, choć Ty niczego nie ruszałeś.
Pierwsza przyczyna to wersje API. Meta deklaruje, że każda wersja Graph API działa co najmniej dwa lata od premiery, a potem zapytania przełączają się na najstarszą wciąż wspieraną. Dwa lata brzmią jak dużo, dopóki nie policzysz, ile usług ma Twój scenariusz i że każda ma własny kalendarz. Bywa też gwałtowniej: w lutym 2023 Twitter ogłosił z tygodniowym wyprzedzeniem koniec darmowego dostępu do swojego API. Każdy scenariusz, który publikował posty przez darmowy dostęp, musiał odtąd albo zacząć płacić, albo przestać działać.
Druga przyczyna to połączenia, które wygasają. Google opisuje, że projekt z ekranem zgody w statusie testowym dostaje token odświeżania ważny siedem dni, a token nieużywany przez pół roku też traci ważność. Ktoś podłączył arkusz przez własną, szybko skonfigurowaną aplikację i po tygodniu scenariusz przestaje mieć dostęp. Stąd błędy autoryzacji z pierwszej sceny.
Trzecia jest najbardziej przyziemna. Ktoś dodał pole w formularzu, zmienił nazwę kolumny w arkuszu albo wkleił do zamówienia emotikon, którego system księgowy nie przyjmuje. Żaden dostawca tego za Ciebie nie wyłapie, bo z jego perspektywy wszystko działa poprawnie.
Każde z trzech narzędzi przerzuca tę robotę w inne miejsce
Nie ma narzędzia, w którym zmiany po drugiej stronie znikają. Różnica polega na tym, ile z ich obsługi bierze na siebie dostawca, a ile ląduje u Ciebie. Im więcej bierze, tym drożej wychodzi jedno wykonanie, i to jest uczciwa wymiana, o ile wiesz, że ją robisz.
Zapier bierze część pilnowania na siebie i dolicza ją do ceny
W Zapierze integrację utrzymuje jej twórca, który wydaje kolejne wersje. Zapier ocenia partnerów także po tym, jak radzą sobie ze zgłoszeniami: dokumentacja dla deweloperów mówi wprost, że mniej otwartych problemów podnosi wynik integracji i poziom w programie partnerskim. Nie znalazłem zdania, które nakładałoby na partnera obowiązek reagowania na każdą zmianę API, ale układ bodźców jest czytelny.
Wygaszanie starych wersji ma ustalone reguły. Autor integracji wyznacza datę od trzech tygodni do roku naprzód, a na czternaście dni przed terminem wychodzi mail z powiadomieniem. Po terminie scenariusze, których nikt nie przestawił, zostają wstrzymane. Zapier przyznaje przy tym, że zmiany w nowej wersji czasem uniemożliwiają automatyczną aktualizację, więc część przestawiania i tak spada na Ciebie.
Po stronie awarii dostajesz sporo w pakiecie. Powiadomienia o błędach przychodzą domyślnie na maila. W planach od Professional w górę działa automatyczne ponawianie: nieudany krok próbuje się jeszcze do pięciu razy, z przerwami od pięciu minut do sześciu godzin. Scenariusz, który sypie się uporczywie, Zapier wyłącza sam, gdy błędy stanowią 95% uruchomień przy ponad dwudziestu przebiegach w tygodniu. Historię przebiegów gwarantuje przez maksymalnie sześćdziesiąt dni.
Dla firmy bez osoby technicznej to główny powód, żeby zostać przy Zapierze. Płacisz więcej za zadanie, a w zamian ktoś inny śledzi zmiany API i przynajmniej próbuje przestawić Twoje scenariusze za Ciebie.
Make daje narzędzia do błędów, a stare moduły wymieniasz sam
Make oddaje Ci więcej kontroli nad tym, co się dzieje, gdy coś pada, i więcej odpowiedzialności za to, żeby scenariusz nie zestarzał się po cichu. Kiedy usługa wydaje nową wersję API, jej aplikacja w Make zostaje w końcu wygaszona, a moduł w Twoim scenariuszu staje się przestarzały. Oznacza go zielona podwójna strzałka. Część aplikacji ma narzędzie do migracji, ale Make zaznacza, że nie wszystkie, więc resztę wymieniasz ręcznie, moduł po module.
Do obsługi awarii Make ma pięć rodzajów reakcji na błąd, a dwa z nich w maju 2026 zmieniły nazwy: dawny Break to teraz Retry, a Ignore to Skip. Pozostałe to Resume, Commit i Rollback. Do tego dochodzą niedokończone wykonania, które zapisują przebieg przerwany błędem, żeby dane nie przepadły. Ta funkcja jest domyślnie wyłączona, więc jeśli jej nie włączysz, nie ma czego wznawiać.
Scenariusz startujący od wyzwalacza natychmiastowego, na przykład od webhooka z formularza, Make wyłącza po pierwszym błędzie, niezależnie od ustawionego limitu. A wygasłych danych logowania nie obsłużysz żadnym z pięciu mechanizmów, bo to błąd, który musi naprawić człowiek.
Logi wykonań trzymane są przez trzydzieści dni w planach Core, Pro i Teams, a przez siedem w darmowym. Jeśli awaria z otwarcia wydarzyła się pięć tygodni temu, po jej śladach nie zostało nic.
n8n na własnym serwerze: pilnujesz scenariuszy i platformy naraz
Przy n8n stawianym u siebie dochodzi warstwa, której w chmurowych narzędziach nie widzisz wcale: sama platforma też się zmienia. Wersja 2.0 z grudnia 2025 przyniosła listę zmian niekompatybilnych. Wśród nich jest koniec obsługi węzła Start, domyślna blokada zmiennych środowiskowych w węźle Code i rezygnacja z MySQL oraz MariaDB jako bazy. Kilka węzłów usunięto, bo usługi, z którymi się łączyły, przestały istnieć. Gałąź 1.x dostała po premierze trzy miesiące wsparcia. Na aktualizację masz więc okno z datą końca.
Jest też dobra wiadomość. Zapisany scenariusz zostaje przy tej wersji węzła, na której go zbudowano, nawet gdy wyjdzie nowsza. Aktualizacja platformy nie przestawia Ci więc po cichu logiki w działających scenariuszach. Tylko że stara wersja węzła nie wie o zmianach w API, więc decyzja o przejściu na nową zostaje po Twojej stronie.
Osobny rozdział to węzły społeczności. Utrzymują je ich autorzy, a n8n ostrzega, że mogą wprowadzać zmiany niekompatybilne w nowych wersjach i mają pełny dostęp do maszyny, na której działa n8n. Węzeł napisany przez jedną osobę w wolnym czasie może być świetny. Może też przestać być rozwijany w dniu, w którym jego API się zmieni.
Mechanizmy awaryjne trzeba sobie złożyć. n8n pozwala każdemu scenariuszowi przypisać osobny scenariusz błędów, który zaczyna się od węzła Error Trigger i może na przykład wysłać wiadomość na Slacka. Nikt go jednak za Ciebie nie ustawi. Historia wykonań w instalacji własnej jest domyślnie czyszczona po 336 godzinach, czyli po dwóch tygodniach. Koszt samego serwera rozpisałem w tekście o n8n. Tu liczy się to, że do utrzymania scenariuszy dopisujesz utrzymanie narzędzia.
Kto robi którą robotę, zestawione w jednym miejscu
Jeśli sprowadzić trzy poprzednie sekcje do jednego pytania, brzmi ono tak: gdy coś się zmieni, czyja to będzie godzina?
| Zapier | Make | n8n na własnym serwerze | |
|---|---|---|---|
| Zmiana API usługi | Autor integracji wydaje nową wersję, Zapier próbuje przestawić scenariusze | Moduł oznaczony jako przestarzały, wymiana ręczna albo migratorem | Nowa wersja węzła, przejście na nią po Twojej stronie |
| Zmiana samej platformy | Niewidoczna dla Ciebie | Niewidoczna, poza zmianami nazw i funkcji | Aktualizacje i zmiany niekompatybilne do przejścia samemu |
| Ponawianie po błędzie | Automatyczne w planach płatnych | Do skonfigurowania, niedokończone wykonania trzeba włączyć | Do zbudowania scenariuszem błędów |
| Kto się dowie o awarii | Właściciel konta, mailem | Właściciel konta, scenariusz bywa wyłączony od razu | Ten, do kogo sam skierujesz powiadomienie |
| Jak długo zostają ślady | Do 60 dni | 7–30 dni zależnie od planu | Domyślnie 14 dni |
Dane w tabeli pochodzą z dokumentacji podlinkowanej w trzech sekcjach wyżej, w stanie z września 2026. Ostatni wiersz wygląda na drobiazg, a rozstrzyga, czy po awarii odtworzysz, które zamówienia przepadły, czy będziesz o to pytać klientów.
Dwadzieścia rzeczy, które robisz ręcznie, a nie musisz
Utrzymanie kosztuje mniej, gdy automatyzujesz procesy stabilne, a nie te, które zmieniają się co miesiąc. Ta lista pomaga wybrać te pierwsze.
Pobierz za darmo →Uruchomić jest łatwo, utrzymać i rozbudować udaje się nielicznym
Podobną lekcję dały wcześniej roboty programowe, czyli RPA, które klikają w interfejsy zamiast rozmawiać przez API. W badaniu Deloitte z 2017 roku, na ponad czterystu organizacjach, tylko 3% firm doprowadziło wdrożenie do skali pięćdziesięciu robotów lub więcej. Rok później ten odsetek wzrósł do 4%.
Raport nie twierdzi, że winne było wyłącznie utrzymanie, i nie ma powodu dopisywać mu tej tezy. Pokazuje za to przepaść między pierwszym działającym robotem a pięćdziesiątym. Przy małej skali to ta sama przepaść: pierwszy scenariusz pilnujesz w głowie, dziesiąty już nie. O tym, jak łatwo automatyzacja zamienia się w obowiązek zamiast ulgi, pisałem we wpisie kiedy automatyzacja staje się pułapką.
Policz godziny, zanim porównasz abonamenty
Nie istnieje rzetelna liczba mówiąca, ile czasu średnio pochłania utrzymanie automatyzacji w małej firmie. Szukałem i nie znalazłem. Da się ją za to oszacować dla własnych scenariuszy, bez żadnych narzędzi.
Wynik będzie szacunkiem i trzeba go tak traktować. Szacunek oparty na własnej ostatniej awarii jest jednak bliższy prawdy niż jakakolwiek tabelka funkcji, bo liczy dokładnie te scenariusze, które masz.
Trzy nawyki, które obcinają utrzymanie w każdym narzędziu
Wybór narzędzia przesuwa robotę, ale jej nie usuwa. Część kosztu da się jednak zbić niezależnie od tego, gdzie stoją scenariusze.
Każdy scenariusz ma przypisaną jedną osobę z imienia. Nie „dział marketingu", nie „ten, kto go zbudował". Kiedy ta osoba odchodzi, scenariusz dostaje nowego właściciela tego samego dnia, a nie przy pierwszej awarii.
Powiadomienie o błędzie trafia tam, gdzie ktoś patrzy codziennie. Mail na skrzynkę, którą dawno temu założył stażysta, ktoś przeczyta dopiero przy porządkach. Przekieruj błędy na komunikator, którego faktycznie używacie.
Lista połączeń z datą utworzenia, kontem, na którym stoją, i terminem wygaśnięcia, jeśli usługa taki podaje. Większość niespodziewanych awarii to połączenie założone na prywatnym koncie albo w trybie testowym, o którym wszyscy zapomnieli.
Żaden z tych nawyków nie wymaga narzędzia. Wymaga decyzji, że scenariusz jest częścią procesu i ma miejsce na czyjejś liście obowiązków. Jeśli w Twojej firmie automatyzacje powstają w odpowiedzi na kolejne pożary, problem zaczyna się przed wyborem narzędzia.
Który rachunek po roku wychodzi najniższy
Zapier wychodzi najtaniej tam, gdzie nie ma nikogo technicznego, a scenariuszy jest kilka. Wyższa cena zadania kupuje Ci to, że ktoś inny śledzi zmiany API, ponawia nieudane kroki i w standardowych planach trzyma historię najdłużej z trójki.
Make ma sens, gdy chcesz sam decydować, co się dzieje przy błędzie, i akceptujesz, że raz na jakiś czas usiądziesz do wymiany przestarzałych modułów. Warunek: ktoś musi te zielone strzałki zauważać, zanim usługa po drugiej stronie wyłączy stare API.
n8n na własnym serwerze wygrywa rachunek wtedy, gdy osoba, która go utrzyma, już jest w firmie i ma na to czas, a scenariuszy jest dużo albo są długie. Jeśli tę osobę dopiero musiałbyś znaleźć, oszczędność na abonamencie zjada pierwsza aktualizacja z listą zmian niekompatybilnych.
Wróć na koniec do poniedziałkowej sceny. Awaria nie zaczęła się w dniu, w którym wygasło połączenie. Zaczęła się wtedy, gdy nikt nie zapisał, kto ma go pilnować.
Sprawdźmy, co da się zdjąć z Twojej głowy
Masz scenariusze, o których wiesz tylko tyle, że na razie działają? Przejdziemy przez nie razem, spiszemy połączenia i ustalimy, które z nich wymagają właściciela, zanim same o to poproszą.
Napisz do mnie →Jeśli wybierasz n8n i chcesz od początku budować scenariusze z obsługą błędów, a nie dokładać ją po pierwszej awarii, pokazuję to krok po kroku w kursie o tworzeniu automatyzacji przy pomocy n8n i AI.
Najczęściej zadawane pytania
To wszystko, co płacisz po wdrożeniu scenariusza, poza samym abonamentem: czas do zauważenia awarii, szukanie przyczyny, naprawa, wymiana przestarzałych modułów i aktualizacje po zmianach API usług, z którymi scenariusz się łączy. W cenniku go nie ma, bo zależy od liczby połączeń i od tego, ile tej pracy dostawca bierze na siebie. Przy małej liczbie scenariuszy bywa niewidoczny, przy kilkunastu potrafi przewyższyć abonament.
Najczęściej zmienia się coś po stronie usługi zewnętrznej. Dostawca wydaje nową wersję API i wygasza starą, połączenie traci ważność, na przykład gdy Google wydaje aplikacji w trybie testowym token odświeżania ważny siedem dni, albo do scenariusza zaczynają trafiać inne dane, bo ktoś dodał pole w formularzu. Sam scenariusz jest poprawny, ale przestaje pasować do usługi, z którą rozmawia.
Zapier automatycznie wyłącza scenariusz, gdy błędy stanowią 95% jego uruchomień i jednocześnie scenariusz uruchomił się ponad dwadzieścia razy w ciągu ostatnich siedmiu dni. Właściciel konta dostaje wcześniej mail z ostrzeżeniem. W planach od Professional w górę działa też automatyczne ponawianie: nieudany krok jest powtarzany do pięciu razy, z rosnącymi przerwami od pięciu minut do sześciu godzin.
Make ma ustawienie określające, ile kolejnych błędów scenariusz może zaliczyć przed wyłączeniem. Wyjątkiem są scenariusze startujące od wyzwalacza natychmiastowego, na przykład webhooka: te Make wyłącza po pierwszym błędzie, niezależnie od ustawienia. Część błędów, jak przekroczenie limitu rozmiaru danych, od razu wyłącza harmonogram. Wygasłych danych logowania nie obsłuży żaden mechanizm obsługi błędów, trzeba je odnowić ręcznie.
Zapisany scenariusz zostaje przy tej wersji węzła, na której go zbudowano, więc zwykła aktualizacja nie zmienia jego logiki. Wersje główne wprowadzają jednak zmiany niekompatybilne. W n8n 2.0 z grudnia 2025 zniknęła obsługa węzła Start, domyślnie zablokowano zmienne środowiskowe w węźle Code i wycofano MySQL oraz MariaDB jako bazę. Przed taką aktualizacją trzeba przejrzeć listę zmian i przetestować scenariusze.
Zapier gwarantuje historię przebiegów przez maksymalnie sześćdziesiąt dni. Make trzyma logi przez siedem dni w planie darmowym i trzydzieści w planach Core, Pro i Teams. Samodzielnie hostowany n8n domyślnie usuwa dane wykonań po czternastu dniach, choć da się to zmienić w konfiguracji. Od tego zależy, czy po wykrytej z opóźnieniem awarii odtworzysz, które dane przepadły.
Zależy od tego, kto w firmie zajmie się scenariuszami. Bez osoby technicznej i przy kilku scenariuszach zwykle wygrywa Zapier, bo część pilnowania zmian API bierze na siebie. Make pasuje, gdy ktoś chce kontrolować obsługę błędów i regularnie wymieniać przestarzałe moduły. n8n na własnym serwerze opłaca się, gdy osoba do jego utrzymania już jest w zespole, a scenariuszy jest dużo albo są długie.
Szymon Mojsak
Ekspert automatyzacji procesów biznesowych i współwłaściciel RCPonline — systemu rejestracji czasu pracy.
Teoria zastosowana w praktyce — treści opieram na własnych doświadczeniach zdobytych przy wdrożeniach i w relacjach międzyludzkich.
Poszerzam horyzonty — nieustannie rozwijam wiedzę z zakresu marketingu, psychologii i IT.
Zamieniam twórczy chaos w kierunek — najpierw pytanie „po co”, dopiero potem „jak”. Pomagam zrozumieć procesy, by je usprawnić.
Ten materiał powstał z udziałem AI
Narzędzia AI — wspierały research, redakcję tekstu i przygotowanie ilustracji.
Autor — wybiera temat, pisze pierwszą wersję i redaguje całość przed publikacją. Doświadczenia, oceny i punkt widzenia w tekście są jego własne.
Ładowanie komentarzy...