Workflow veikia, bet nieko nevyksta: kaip rasti tylų gedimą

Skundas skamba nekaltai, kol nesuskaičiuojate, kiek užsakymų dėl jo praradote: workflow veikia, bet nieko nevyksta. Vykdymų sąrašas žalias nuo viršaus iki apačios. Jokio raudono ženkliuko, jokio n8n laiško, jokios klaidos, o potencialių klientų CRM vis tiek nėra, dokumentai nesugeneruoti, o klientas, antradienį užpildęs formą, vis dar laukia atsakymo. Tada žmonės ieško „nėra klaidos, bet neveikia“ ir randa forumų temas, į kurias niekas taip ir neatsakė.

Žalias vykdymas reiškia tik tiek, kad nė vienas mazgas neišmetė klaidos. Ar buvo atliktas koks nors darbas, jis visiškai nepasako.

Pažiūrėkite elementų skaičių ties kiekvienu mazgu

Atidarykite vykdymą ir eikite iš kairės į dešinę, žiūrėdami mažą elementų skaitiklį virš kiekvieno mazgo. Štai tikras vykdymas iš workflow, perkeliančio formas į CRM, kuris jau kelias dienas „veikė“:

Execution 91744   Status: Success   Duration: 0.42 s

  Webhook               in 1    out 1    4 ms
  Code (normalise)      in 1    out 1    11 ms
  Filter (is qualified) in 1    out 0    2 ms
  Loop Over Items       in 0    out 0    1 ms
  HTTP Request (CRM)                     not executed
  Slack (notify AE)                      not executed

n8n požiūriu šis vykdymas sėkmingas. Tačiau jis nieko nepadarė. Filter mazgas gavo vieną elementą ir neišleido nė vieno, todėl visiems toliau esantiems mazgams nebuvo ką veikti, o mazgas be įvesties apskritai nevykdomas. n8n to nelaiko klaida, nes techniškai tai ir nėra klaida: filtrui tuščias rezultatas yra visiškai normalus.

Prieš dvi savaites tas Filter tikrino lauką lead_score. Kažkas CRM sistemoje jį pervadino į leadScore. Dabar Code mazgas į savybę, kurią skaito Filter, įrašo undefined, palyginimas nepavyksta nė vienam potencialiam klientui, ir nuo tada workflow tyliai atmeta juos visus.

Workflow veikia, bet nieko nevyksta, nes formaliai niekas nesugedo

Žmonės tai apibūdina skirtingai, bet visais atvejais tai ta pati problema: workflow vykdomas, bet rezultatas neatkeliauja; vykdymas žalias, o įrašo nėra; scenarijus baigėsi greičiau nei per sekundę ir nieko nepadarė. Beveik visus mūsų matytus atvejus apima keturi variantai, ir kiekvienas iš jų baigiasi žaliu vykdymu.

• Elementai atfiltruojami iki nulio. Filter, IF šaka ar Remove Duplicates mazgas išmeta viską, dažniausiai po lauko pervadinimo arba pasikeitus gaunamų duomenų struktūrai.
• Klaida slypi sėkmingame atsakyme. Daug API atsako 200, o atsakymo turinyje parašyta, kad įrašas atmestas. n8n mato 200 ir ramiai vykdo toliau.
• Kažkur įjungtas Continue On Fail. Šis variantas pridaro daugiausia žalos, nes klaida tampa įprastais duomenimis ir keliauja toliau, lyg būtų įrašas.
• Darbas atliekamas ten, kur nežiūrite. Workflow rašė į bandomąją (sandbox) paskyrą, testinę skaičiuoklę ar testinį CRM, nes testuojant buvo pakeisti prisijungimo duomenys ir jų niekas negrąžino.

Trečiąjį variantą verta pamatyti tikruose duomenyse. Kai On Error nustatyta tęsti naudojant įprastą išvestį (regular output), nepavykęs HTTP Request išleidžia štai ką:

[
  {
    "json": {
      "error": "Insufficient scope: contacts.write",
      "httpCode": "403"
    },
    "pairedItem": { "item": 0 }
  }
]

Tai vienas išleistas elementas, todėl skaitiklis rodo 1, o varnelė žalia. Toliau Set mazgas iš to elemento paima id, nieko negauna, o Google Sheets mazgas prideda tuščią eilutę. Esame matę workflow, kurie taip veikė mėnesius ir pildė skaičiuoklę tuščiomis eilutėmis, kurių visi tiesiog nebepastebėdavo. 403 čia reiškia, kad tokenas galioja, bet teisių srities (scope) nebėra. Todėl klaida kartodavosi kiekvieną kartą, kai reikėdavo įrašyti kontaktą, o vienintelis matomas požymis buvo tuščios eilutės.

Yra ir susijęs nustatymas, kurį verta žinoti iš anksto. Always Output Data priverčia mazgą, kuris nieko negrąžina, vietoj to išleisti vieną tuščią elementą:

[ { "json": {}, "pairedItem": { "item": 0 } } ]

Žmonės jį įjungia, kad šaka nesustotų, ir ji tikrai nesustoja. Tačiau tada „kliento neradome“ virsta „štai klientas be jokių laukų“, ir toks tuščias klientas vėliau kur nors įrašomas.

Dešimt minučių patikrų

1. Palyginkite greta sėkmingą ir tuščią vykdymą. Raskite paskutinį mazgą, kuriame abiejų vykdymų elementų skaičiai dar sutampa. Iškart po jo esantis mazgas yra ta vieta, kur dingsta Jūsų duomenys. Vien šis palyginimas išsprendžia daugiau tokių atvejų nei visa kita šiame puslapyje.
2. Atidarykite to mazgo išvestį ir, išskleidę elementą, pažiūrėkite tikrąjį JSON. Ieškokite undefined reikšmių, error savybės, kuriai ten ne vieta, arba lauko pavadinimo camelCase formatu, kai Jūsų išraiška naudoja snake_case.
3. Patikrinkite, ar paleidiklis (trigger) apskritai gauna tai, ką manote. n8n webhook Test URL klausosi tik tol, kol veikia Listen For Test Event, o Production URL atsako tik tada, kai workflow aktyvus. Siuntėjas, nukreiptas ne tuo adresu, gauna 404 ir, priklausomai nuo sistemos, Jums apie tai gali niekada nepranešti.
4. Ieškokite prisegtų duomenų. Prisegti duomenys taikomi tik rankiniams vykdymams, todėl workflow gali praeiti kiekvieną redaktoriuje atliktą testą ir gamybinėje aplinkoje neapdoroti nieko, nes redaktorius nuo kovo jam tiekia tuos pačius išsaugotus duomenis. Prisegimo piktograma ant mazgo maža, ją lengva pražiūrėti.

Jei 3 žingsnis parodo, kad paleidiklis visai nustojo suveikti, problema kyla dar anksčiau, nei aprašyta čia. Kaip nustatyti, kada kas pasikeitė, paaiškina puslapis apie automatizaciją, kuri nustojo veikti.

Įspėjimas, kai vykdymas nieko nepadarė

Integruoti n8n įspėjimai nė vienu iš aukščiau aprašytų atvejų nepadės. Error Trigger suveikia dėl klaidų, o nė vienas iš šių atvejų nėra klaida. Vykdymo, kuris baigiasi be klaidos ir nieko nepadaro, nepastebi joks platformos pranešimas. Todėl šio puslapio pradžioje aprašytas workflow tuščiai veikė daugiau nei savaitę, kol kas nors paklausė, kur dingo potencialūs klientai.

Todėl tenka tiesiogiai tikrinti, ar darbas atliktas. Šiame puslapyje pateikta patikra paleidžiama pagal grafiką, per vykdymų API tikrina nurodytus workflow ir įspėja vienu iš dviejų atvejų: workflow, kuris paprastai vykdomas, per nustatytą laiką apskritai nebuvo paleistas, arba jis įvykdytas, bet paskutinis mazgas nepateikė nė vieno elemento. Nukreipkite ją į tuos keturis ar penkis workflow, kurių sustojimas Jums kainuoja pinigus, nustatykite laiką šiek tiek ilgesnį nei įprastas tarpas tarp vykdymų, ir daugiau jos liesti nereikės.

Mūsų sukurtos sistemos kasdien veikia klientų įmonėse, ir kiekviena, kurią prižiūrime, turi tokią patikrą. Kodėl, gerai parodo dokumentų generatorius, kurį sukūrėme hidrogeologijos konsultacijų įmonei. 2026 m. rugpjūčio duomenimis jis yra sugeneravęs 168 dokumentus ir saugo 349 gręžinių duomenis, o jo gedimai niekada nebuvo klaidos. Tai buvo vykdymas, kuris per pusę sekundės baigėsi nieko nesugeneravęs, nes tą mėnesį šaltinio faile stulpelio antraštė buvo užrašyta šiek tiek kitaip. Patikra praneša, kiek dokumentų sugeneruota per kiekvieną vykdymą, o nulis iš karto atkeliauja kaip įspėjimas, dar prieš pastebint klientui.

Išvesties skaičiavimas yra pigiausias būdas taikyti tą patį principą, kuriuo grindžiamas verslo automatizacijų testavimas: nuspręskite, ką turi duoti tvarkingas vykdymas, ir matuokite tai kiekvieną kartą, o ne pasitikėkite ženkliuko spalva.

Kada pagalbos nereikia

Daug tylių gedimų sutaisoma per dešimt minučių, ir tokiu atveju geriau tai pasakysime iš karto, nei imsime 450 € už diagnostiką. Taisykite patys, kai:

• 1 žingsnio palyginimas nuveda į Filter ar IF, o lauko pavadinimas išraiškoje nebeatitinka lauko pavadinimo duomenyse. Pataisykite išraišką ir dar kartą paleiskite nepavykusius vykdymus.
• Ant paleidiklio randate prisegtų duomenų. Pašalinkite prisegimą (Unpin), vieną kartą paleiskite workflow realiai ir įsitikinkite, kad atkeliauja tikri duomenys.
• Prisijungimo duomenys nukreipti į bandomąją aplinką. Pakeiskite juos, o tada patikrinkite, kas nuo to laiko buvo įrašyta į bandomąją aplinką, nes tuos įrašus vis tiek reikės perkelti.
• Continue On Fail įjungtas mazgui, kuris rašo įrašus, ir elemento išvestyje matote tikrąją klaidą. Išjunkite jį, pataisykite klaidą, kurią jis slėpė, ir būkite pasiruošę, kad kurį laiką workflow lūš su klaidomis. Tai gerai: dabar gedimai matomi.

Kreipkitės pagalbos, kai dingusių duomenų atvejo nepavyksta atkartoti, kai workflow priklauso nuo Merge mazgo, kurio elgesio niekas įmonėje negali paaiškinti, kai Split In Batches ciklas su dideliais JSON duomenimis didina atminties naudojimą tol, kol konteineris persikrauna vykdymo viduryje ir palieka pusę įrašų apdorotų, arba kai klaidą radote, bet negalite pasakyti, kiek įrašų dingo, kol ji veikė. Pastarasis klausimas dažniausiai ir kainuoja daugiausia, todėl pradedame nuo raštiškos diagnostikos, o ne nuo skubaus pataisymo.

Kiek kainuoja taisymas

Diagnostika kainuoja 450 € ir užtrunka dvi darbo dienas. Gaunate raštišką dokumentą, kuriame įvardytas tylus gedimas, jį įrodantys vykdymo duomenys, kiek įrašų paveikta ir nuo kada problema tęsiasi, bei fiksuota taisymo kaina. 450 € visa suma įskaitoma į tą kainą. Viena sugedusi šaka su vėliau pridėtais įspėjimais paprastai kainuoja nuo 700 iki 1 400 € ir užtrunka 2-5 dienas. Kai tame pačiame workflow yra keli tokie gedimai ir jų priežastis yra struktūra, tai jau standartinis taisymas, kuris kainuoja nuo 1 400 iki 3 700 € ir trunka 1-2 savaites. Visiškas kūrimas iš naujo kainuoja nuo 3 700 iki 9 200 € ir trunka 2-4 savaites, ir jį rekomenduojame tik tada, kai taisymas kainuotų daugiau nei kūrimas iš naujo. Kiekvienam darbui taikoma 30 dienų garantija klaidoms.

Prieš nuspręsdami, perskaitykite du tekstus: kodėl automatizacijos nustoja veikti po paleidimo, kur tylus gedimas yra dažniausiai mūsų matomas, ir AI sistemos paruoštumo kontrolinį sąrašą, kurį perduodame taisymo pabaigoje, kad kitas tylus gedimas truktų valandą, o ne devynias dienas.

Jei norite, kad pažiūrėtume, per taisymo užklausos formą atsiųskite workflow pavadinimą ir nuorodą į vieną žalią vykdymą, kuris turėjo kažką padaryti, arba perskaitykite, kaip dirbame, taisymo paslaugos puslapyje.