n8n haladó tippek: hibakezelés és monitoring beállítása

Az automatizálás első hete mindig szép. Megépíted a workflow-t, lefut, és elhiszed, hogy ezzel kész. Aztán három hét múlva kiderül, hogy valami két hete elhasal minden éjjel, és senki nem szólt. Az n8n hibakezelés nem haladó luxus, hanem az a réteg, amitől az automatizálásod nem csak működik, hanem meg is bízhatsz benne.

Ez a cikk arról szól, mit állíts be, amikor az első workflow-d már fut. Ha még csak ismerkedsz az eszközzel, előbb nézd meg, mi az az n8n és mire jó.

A legdrágább hiba az, amelyikről nem tudsz

Ha egy workflow futás közben hibára fut, az n8n megállítja, és a futás hibás állapotban lezárul. Ennyi. Nem küld e-mailt, nem villog semmi, a folyamat egyszerűen nem történik meg. A számla nem megy ki, az érdeklődő nem kerül be a CRM-be, a riport nem készül el.

És pont ez a veszélyes benne: a néma hiba ugyanúgy néz ki, mint a nyugalom. Ha egy automatizmus naponta öt új érdeklődőt visz a rendszerbe, és holnaptól nullát visz, azt a felületen nem látod — csak azt, hogy „ma nem jött megkeresés”. Magunkon mértük: egy elrontott beállítás négy napig ment úgy, hogy közben minden zöldnek látszott.

Ezért az első kérdés nem az, hogy hogyan előzd meg a hibát. Hanem az, hogy honnan fogod megtudni, ha bekövetkezik.

Error workflow: a legolcsóbb biztosítás, amit beállíthatsz

Az n8n-ben külön workflow-t tudsz kijelölni arra az esetre, ha egy másik elhasal. Ez a hibakezelő folyamat: egy Error Trigger node-dal indul, és te döntöd el, mi történjen, amikor meghívódik.

A menete egyszerű:

1. Készíts egy új workflow-t, az első node legyen az Error Trigger.
2. Kösd rá azt, ahol biztosan észreveszed: e-mail, Telegram-üzenet, Slack, akár egy sor egy táblázatban.
3. A védeni kívánt workflow beállításai közt add meg ezt a folyamatot hibakezelőként.

Az értesítésbe tedd bele a workflow nevét, a hibaüzenetet és a futás azonosítóját. Egy „valami elromlott” üzenettel nem tudsz mit kezdeni; egy „Számlázás workflow, Billingo node, 401″ üzenettel viszont harminc másodperc alatt megvan, mi a baj.

Egy hibakezelő workflow több folyamatot is kiszolgálhat, tehát ezt tényleg elég egyszer megépítened.

Újrapróbálkozás: mikor segít, és mikor csak elfedi a bajt

A node-ok beállításai közt bekapcsolható az automatikus újrapróbálkozás: ha a művelet elhasal, az n8n megvárja a beállított időt, és újra megpróbálja. Ez a hibák egy jelentős részét megoldja anélkül, hogy bárkinek foglalkoznia kellene vele.

Akkor van értelme, ha a hiba átmeneti:

• a másik szolgáltatás pillanatnyilag nem válaszol vagy időtúllépést ad
• kifutottál egy percenkénti kéréskorlátból
• hálózati hiba jött közbe

És akkor nincs értelme, ha a hiba állandó: rossz jelszó, lejárt hozzáférés, hiányzó kötelező mező, elgépelt azonosító. Ilyenkor az újrapróbálkozás csak háromszor annyi ideig tart, mire ugyanaz a hiba jön ki — és közben az az érzésed, hogy „hát próbálkozik”.

Praktikus alapbeállítás: külső API-hívásra 2-3 próbálkozás, néhány másodperc szünettel. Adatbázis-írásra és fájlműveletre óvatosabban, mert ott a duplikáció kockázata valós.

Részleges siker: amikor jobb továbbmenni, mint megállni

Alapból egyetlen hibás elem az egész futást megállítja. Sokszor ez a helyes viselkedés — de nem mindig.

Képzeld el, hogy száz ügyfélnek küldesz értesítőt, és a negyediknél hibás az e-mail-cím. Ha a folyamat ott megáll, kilencvenhat ember nem kap semmit egy elgépelés miatt. A node hibakezelési beállításánál megadhatod, hogy hiba esetén ne álljon le, hanem menjen tovább — és a hibás elemeket külön ágon kezeld le.

A szabály, amit érdemes követni: ha az elemek egymástól függetlenek, menj tovább; ha egymásra épülnek, állj meg. Egy hírlevél-kiküldésnél a részleges siker jobb a semminél. Egy „számlát állítok ki, majd elküldöm, majd könyvelem” láncnál viszont nem: ott a fél-kész állapot rosszabb, mint a tiszta leállás.

Ha továbbmész hiba után, a hibás elemeket mindenképp gyűjtsd ki valahová. Különben pont az veszik el, amit kézzel pótolnod kellene.

Monitoring: ne akkor tudd meg, amikor az ügyfél szól

A hibakezelés arra jó, ha valami elromlik. A monitoring arra, hogy tudd, mi a normális.

Három dolog, amit érdemes beállítanod:

• A futások listája legyen valóban átnézhető. Ellenőrizd, hogy a sikertelen futások mentése be van kapcsolva — ha nem, pont a hibás eseteket nem tudod utólag megnézni.
• Heti egy pillantás. Nézd végig, mennyi futás volt és mennyi hasalt el. A hibaarány elmozdulása hamarabb szól, mint bármelyik egyedi hiba.
• Csend-figyelés. Ez a legfontosabb, és ezt hagyja ki mindenki. Ha egy workflow-nak naponta futnia kell, akkor arról is kapnod kell jelzést, ha nem futott. A hiba zajt csinál, a kimaradás nem.

A csend-figyelés egyszerűen megépíthető: egy ütemezett workflow megnézi, volt-e futás az elmúlt 24 órában, és ha nem, szól. Ez az a jelzés, ami a „két hete nem megy semmi” típusú meglepetéseket kiszűri.

A zöld pipa nem bizonyíték

Van egy tanulság, amit a saját rendszerünkön tanultunk meg, és minden automatizálásra igaz: attól, hogy egy folyamat sikeresnek jelenti magát, még nem biztos, hogy megtörtént az, amit akartál.

Volt egy folyamatunk, ami közösségi posztot tett ki. Zöld pipával jelzett, a naplóban minden rendben volt — a kép viszont nem ment ki vele, csak a szöveg. A folyamat a maga szempontjából tényleg sikeres volt: elküldte a kérést, kapott rá választ. Csak épp nem azt ellenőrizte, ami számított.

Ezért érdemes az ellenőrzést az eredményre tenni, ne a lépésre: ne azt nézd, hogy a hívás lefutott-e, hanem azt, hogy a számla tényleg létrejött-e, a poszt tényleg kint van-e, a sor tényleg beírásra került-e. Egy plusz lekérdezés a folyamat végén többet ér, mint tíz zöld pipa.

Mivel kezdd, ha most állsz neki

Nem kell egyszerre mindent bevezetned. Ebben a sorrendben térül meg a leggyorsabban:

1. Egy hibakezelő workflow, ami értesítést küld — ez egyszer megépül, és minden folyamatodat védi.
2. Újrapróbálkozás a külső szolgáltatásokat hívó node-okon.
3. Végigondolod, hol jobb a részleges siker, és hol a tiszta leállás.
4. Csend-figyelés a napi folyamatokra.
5. Eredmény-ellenőrzés ott, ahol a hibának valódi ára van: pénz, ügyfél, határidő.

Ha konkrét példát keresel arra, hogyan néz ki mindez egy éles folyamatban, nézd meg, hogyan automatizáld a számlázást n8n-nel. Ha pedig még az eszközválasztásnál tartasz, itt hasonlítottuk össze a Zapier, az n8n és a Make lehetőségeit.

Az automatizálás akkor ér valamit, ha nem kell naponta ellenőrizned. Ehhez viszont egyszer be kell építened azt, ami helyetted figyel. Ha ebben segítség kellene, vedd fel velünk a kapcsolatot — megnézzük, hol a legnagyobb kockázat a jelenlegi folyamataidban.

Ez a cikk mesterséges intelligencia közreműködésével készült. A szöveget Dobó Imre szerkesztette és ellenőrizte. A cikkben szereplő képek egy része mesterséges intelligenciával generált.