Historia i logi wykonań

Spis treści:

• Przeglądanie historii uruchomień
• Status wykonania: sukces, błąd, pominięty
• Szczegółowy log kroku — diagnostyka błędów
• Ponowne uruchomienie nieudanego workflow

---

Sembot rejestruje każde uruchomienie workflow — kiedy się odbyło, jak długo trwało, czy zakończyło się sukcesem i co dokładnie wykonał każdy blok. Dzięki temu możesz sprawdzić czy automatyzacja działa poprawnie, zdiagnozować błędy i podjąć świadomą decyzję o ponownym uruchomieniu.

---

Przeglądanie historii uruchomień

Historia uruchomień dostępna jest bezpośrednio z poziomu edytora workflow — w górnej belce kliknij przycisk „Historia wykonań" (ikona zegara). Otworzy się panel po prawej stronie z listą wszystkich dotychczasowych uruchomień tego workflow'u.

Co widać na liście uruchomień:

Informacja	Co oznacza
Status	Kolorowy znacznik: sukces, błąd, trwa, anulowane
Data uruchomienia	Kiedy workflow się uruchomił (data i godzina)
Czas trwania	Ile milisekund zajęło wykonanie (np. 1 240 ms)
Typ triggera	Co uruchomiło workflow: harmonogram, webhook, ręcznie
Komunikat błędu	Jeśli workflow nie powiódł się — skrócona informacja o błędzie

Lista odświeża się automatycznie co 10 sekund — nie musisz ręcznie klikać odświeżenia podczas oczekiwania na zakończenie bieżącego uruchomienia. Możesz też kliknąć przycisk „Odśwież" (ikona kółka) w dowolnym momencie.

Kliknięcie dowolnej pozycji na liście otwiera widok szczegółowy tego uruchomienia.

📸 [SCREEN: panel „Historia wykonań" po prawej stronie edytora — lista uruchomień z kolorowymi znacznikami statusu, datami, czasem trwania i typem triggera]

---

Status wykonania: sukces, błąd, pominięty

Każde uruchomienie oraz każdy blok w ramach uruchomienia ma przypisany status.

Statusy uruchomienia (poziom całego workflow'u):

Status	Kolor	Co oznacza
success	Zielony	Wszystkie bloki wykonały się poprawnie
failed	Czerwony	Przynajmniej jeden blok nie powiódł się i workflow zatrzymał się
running	Niebieski	Workflow jest aktualnie w trakcie działania
cancelled	Szary	Uruchomienie zostało ręcznie zatrzymane przez użytkownika

Statusy bloków (poziom pojedynczego węzła):

Status	Kropka	Co oznacza
success	Zielona	Blok wykonał się poprawnie, zwrócił dane
error	Czerwona	Blok nie powiódł się — szczegóły dostępne po kliknięciu
running	Niebieska	Blok jest aktualnie realizowany
skipped	Szara	Blok nie został wykonany, bo warunek If skierował przepływ inną ścieżką

Blok ze statusem skipped nie jest błędem — to zamierzone działanie workflow'u, gdy dana ścieżka warunkowa nie jest aktywna.

📸 [SCREEN: widok szczegółowy uruchomienia — oś czasu bloków z kolorowymi kropkami przy każdym węźle; widoczne bloki zielone, czerwone i szare]

---

Szczegółowy log kroku — diagnostyka błędów

Kliknięcie konkretnego bloku na osi czasu uruchomienia rozwija jego szczegóły. To główne narzędzie do diagnozowania problemów.

Co widać po rozwinięciu bloku:

Sekcja	Zawartość
Błąd	Komunikat o błędzie (widoczny tylko gdy blok się nie powiódł)
Dane wejściowe	Parametry przekazane do bloku — wartości zmiennych z poprzednich bloków już po ich podstawieniu
Dane wyjściowe	Dane zwrócone przez blok — to co będą widzieć następne bloki
Czas wykonania	Ile milisekund zajął ten konkretny blok

Jak korzystać z logów do diagnozy:

1. Otwórz historię uruchomień i kliknij uruchomienie ze statusem „Błąd".
2. Na osi czasu znajdź blok z czerwoną kropką.
3. Kliknij ten blok — rozwinęła się sekcja z komunikatem błędu.
4. Sprawdź sekcję Dane wejściowe — czy zmienne zostały poprawnie podstawione? Czy wartości wyglądają jak oczekujesz?
5. Jeśli poprzedni blok się powiódł, sprawdź jego Dane wyjściowe — czy zawierają pola których oczekujesz i pod właściwymi nazwami?

Typowe przyczyny błędów wykrywane przez logi:

• Blok nie dostał danych bo poprzedni blok zwrócił pustą listę
• Nazwa zmiennej w wyrażeniu nie zgadza się z polem w danych wyjściowych (literówka)
• Zewnętrzne API zwróciło błąd — widoczny w komunikacie błędu bloku HTTP Request
• Timeout — blok działał zbyt długo i system go przerwał
• Agent AI nie odpowiedział w oczekiwanym formacie

Uwaga: Dane wejściowe i wyjściowe bloków mogą być obcięte jeśli są bardzo duże — system pokazuje maksymalnie 5 000 znaków. Przy bardzo dużych odpowiedziach (np. duże dane z Google Ads) część zawartości będzie oznaczona jako _truncated: true.

📸 [SCREEN: rozwinięty blok z czerwoną kropką — widoczny komunikat błędu na górze, poniżej sekcje „Dane wejściowe" i „Dane wyjściowe" z wartościami JSON]

---

Ponowne uruchomienie nieudanego workflow

Sembot nie posiada przycisku „wznów od miejsca błędu" — każde ponowne uruchomienie startuje od początku. Masz do tego kilka sposobów.

Sposób 1 — z listy workflow'ów:

W panelu głównym Workflow → Lista przy każdym workflow'ie dostępna jest opcja „Uruchom teraz" w menu kontekstowym (trzy kropki). Uruchamia workflow natychmiast, niezależnie od harmonogramu.

Sposób 2 — z edytora:

W górnej belce edytora kliknij przycisk „Uruchom workflow" (ikona play). Otwiera się Inspektor workflow po prawej stronie z podglądem bieżącego wykonania na żywo.

Sposób 3 — konfiguracja automatycznych ponowień dla bloku:

Jeśli workflow regularnie zawodzi na konkretnym bloku (np. zewnętrzne API bywa niedostępne), możesz skonfigurować automatyczne ponowienia dla tego bloku — bez konieczności ręcznego uruchamiania.

Kliknij blok w edytorze → panel właściwości po prawej → sekcja ustawień zaawansowanych:

Opcja	Co robi
Kontynuuj przy błędzie	Workflow nie zatrzymuje się gdy ten blok zawiedzie — idzie dalej do następnych bloków
Ponów przy błędzie	Automatycznie ponawia ten blok jeśli się nie powiedzie
Maks. ponowień	Ile razy ponowić próbę (1 – 5)
Timeout (sekundy)	Maksymalny czas wykonania tego bloku (po przekroczeniu — błąd)

Przykład konfiguracji dla niestabilnego API:

Ponów przy błędzie:      ✓ Włączone
Maks. ponowień:          3
Kontynuuj przy błędzie:  ✗ Wyłączone

Efekt: jeśli API nie odpowie, Sembot spróbuje jeszcze 3 razy. Dopiero jeśli wszystkie 4 próby zawiodą — workflow zatrzymuje się z błędem.

Ustawienia ponowień konfiguruje się na poziomie każdego bloku osobno. Blok pobierania danych może mieć 3 ponowienia, a blok HTTP Request — tylko 1.

📸 [SCREEN: panel właściwości bloku z rozwiniętą sekcją zaawansowanych ustawień — widoczne przełączniki „Kontynuuj przy błędzie", „Ponów przy błędzie", pola maks. ponowień i czasu oczekiwania]