Co uruchamia automatyzację: harmonogram, webhook czy czat

Kategoria: Automatyzacja i autonomia

„Co uruchamia te wszystkie automatyzacje?” Odpowiedź jest mniej efektowna niż samo pytanie i, co ważniejsze, można ją policzyć.

Pracuję na jednej instancji n8n uruchomionej na własnym serwerze domowym, z bazą PostgreSQL pod spodem. W n8n każda automatyzacja zaczyna się od jednego bloku nazywanego wyzwalaczem (trigger). Blok ten nie wykonuje żadnej pracy poza oczekiwaniem na sygnał, a dopiero gdy sygnał nadejdzie, uruchamia się reszta. Wszystkie wyzwalacze odczytałem bezpośrednio z bazy 29 października 2026 i każda liczba w tym tekście jest pomiarem z tego jednego dnia.

Dlaczego wyzwalacz waży więcej niż reszta workflow

Blok wyzwalacza odpowiada wyłącznie na pytanie „kiedy”. Wszystkie pozostałe bloki odpowiadają na pytanie „co”. Z mojego doświadczenia wynika, że błąd w części „co” ujawnia się natychmiast: wiadomość nie wychodzi, dane trafiają w niewłaściwe miejsce. Błąd w części „kiedy” potrafi pozostać niezauważony tygodniami, ponieważ automatyzacja po prostu nie uruchamia się wtedy, kiedy powinna, a nikt na nią nie czeka.

Wyzwalacz wybiera się raz i rzadko zmienia

Bloki wewnątrz workflow przestawiam stale. Wyzwalacz zmieniam niemal nigdy, ponieważ jego zmiana oznacza w praktyce napisanie automatyzacji od nowa: zmienia się zarówno to, co trafia na wejście, jak i częstotliwość uruchomień. Z tego powodu ten jeden wybór traktuję poważniej niż wszystkie pozostałe.

Co stoi na początku moich workflow

W bazie znajdują się 223 workflow, a samą tę liczbę rozkładam na części w tekście o tym, co właściwie znaczy ponad 150 workflow w n8n. Poniżej zestawiam bloki wyzwalaczy, które w nich odnalazłem, uszeregowane według liczby wystąpień.

Dlaczego suma przekracza liczbę workflow

Osiem powyższych wartości sumuje się do 334, podczas gdy workflow jest 223. Nie jest to błąd rachunku, lecz informacja sama w sobie. Jeden workflow może zawierać więcej niż jeden blok wyzwalacza i u mnie bardzo często zawiera dokładnie dwa: właściwy oraz ręczny, który pozwala uruchomić automatyzację bez oczekiwania na sygnał. Czterdzieści osiem bloków ręcznego uruchomienia nie opisuje więc sposobu pracy. To przyciski służące do testów, które pozostały w workflow po tym, jak przestały być potrzebne.

Harmonogram, czyli wybór domyślny

Sześćdziesiąt trzy bloki oczekują na sygnał zegara. Jest to najliczniejszy wyzwalacz spośród reagujących na świat zewnętrzny, a nie na inną automatyzację, i wynika to z dwóch jego cech: jest najprostszy do skonfigurowania i najtrudniejszy do zepsucia. Nie wymaga adresu, nie wymaga niczego po drugiej stronie i działa tak samo w dniu konfiguracji oraz rok później.

Czego harmonogram nie potrafi

Harmonogram nie wie, czy cokolwiek się wydarzyło. Sprawdza stan na ślepo i w większości przebiegów nie znajduje nic nowego. Jeżeli reakcja ma nastąpić w ciągu sekund od zdarzenia, zegar jest narzędziem niewłaściwym: trzeba by ustawić go tak gęsto, że samo sprawdzanie kosztowałoby więcej niż obsługiwana sprawa.

Webhook, czyli sygnał z zewnątrz

Czterdzieści bloków oczekuje na wiadomość przychodzącą z innego systemu. Jest to odwrotność harmonogramu: nie sprawdzam niczego, ponieważ o zdarzeniu informuje mnie druga strona. Opóźnienie spada z „do następnego sprawdzenia” do ułamka sekundy.

Ceną webhooka jest utrzymanie

Webhook jest adresem, który musi pozostawać dostępny z zewnątrz i który trzeba zabezpieczyć, ponieważ w przeciwnym razie automatyzację uruchomi każdy, kto ten adres zna. Dlatego nie stosuję webhooka tam, gdzie wystarcza zegar. W automatyzacji domu zależność jest ta sama: opisałem siedem lat z Home Assistantem i to, co się przez ten czas psuło, a psuło się niemal wyłącznie to, co wymagało stałej dostępności.

Czat, czyli wyzwalaczem jestem ja

Trzydzieści cztery bloki oczekują na wiadomość w oknie czatu, a dwadzieścia na wiadomość w Telegramie. Łącznie daje to pięćdziesiąt cztery miejsca, w których automatyzacja nie rozpoczyna się bez mojego udziału. Nie uznaję tego za słabość rozwiązania. Opisałem miesiąc, w którym system przestał mnie pytać, lecz tamta zmiana dotyczyła podejmowania decyzji, a nie momentu startu. Istnieją zadania, których nie chcę uruchamiać zegarem, ponieważ ich sensem jest to, że zostały zlecone. To, co odpowiada po drugiej stronie takiego czatu, policzyłem osobno: 229 bloków modeli, z czego 10 na mojej maszynie.

Największa grupa nie jest wyzwalaczem

Siedemdziesiąt dziewięć bloków, czyli najwięcej ze wszystkich, oczekuje na wywołanie przez inny workflow. Takiej automatyzacji nie dotyka nic z zewnątrz: nie ma zegara, nie ma adresu, nie ma okna czatu. Jest częścią większej całości, a uruchamia ją workflow sąsiedni. Zjawisko to omawiam w osobnym tekście o tym, dlaczego nie mam jednego dużego workflow.

Zasada, którą stosuję przy wyborze

Po dwóch latach sprowadza się ona do trzech pytań zadawanych w ustalonej kolejności:

• Czy druga strona potrafi mnie zawołać? Jeżeli tak, wybieram webhook.
• Czy opóźnienie kilku godzin cokolwiek psuje? Jeżeli nie, wybieram harmonogram, i to rzadki.
• Czy zadanie ma sens wyłącznie wtedy, gdy sam o nie poproszę? Jeżeli tak, wybieram czat.

Kolejność nie jest przypadkowa: wybieram najtańszy w utrzymaniu wyzwalacz, który załatwia sprawę, a nie najszybszy.

Osiem rodzajów i suma 334

• Zliczam bloki, nie workflow. Jeden workflow z dwoma wyzwalaczami występuje w tabeli dwukrotnie, stąd suma 334 zamiast 223.
• Tabela obejmuje osiem najczęstszych rodzajów. Wyzwalacze rzadsze, występujące pojedynczo, nie zmieściły się w pomiarze, z którego ją zbudowałem, i nie podaję ich jako zer.
• Nie mówi, ile razy cokolwiek się uruchomiło. Workflow z jednym blokiem harmonogramu może pracować co pięć minut albo raz w miesiącu i w tabeli wygląda identycznie. Liczbę samych uruchomień podaje dziennik przebiegów.
• Nie mówi, czy wyzwalacz jest włączony. Blok w wyłączonym workflow nie oczekuje na nic, a w tabeli jest obecny.
• Opisuje jeden dzień. Pomiar z 29 października 2026.