Automatizacija nustojo veikti: kaip rasti, kas pasikeitė

Pirmoje žinutėje, kurią mums atsiunčia klientai, dažniausiai parašyta: „automatizacija nustojo veikti, nors niekas jos nelietė“. Dažniausiai tai tiesa. Workflow, kuris aštuonis mėnesius veikė be priekaištų, per naktį savaime nesugenda. Jei n8n workflow staiga nustoja veikti, kažkas pasikeitė, tik ne Jūsų pusėje, ir to pakeitimo laiką galima rasti.

Toliau aprašome, kaip dirbame, kai klientas mums perduoda sustojusį workflow, ir kokius duomenis žiūrime kiekviename žingsnyje. Ta pati tvarka tinka ir sustojusiam Zap ar nutilusiam Make scenarijui, nes ji remiasi vykdymų duomenimis, o ne konkrečios platformos ypatybėmis.

Atidarykite pirmą nepavykusį vykdymą

Vykdymų sąrašas surikiuotas nuo naujausių, o Jums reikia atvirkščiai. Praslinkite pro naujausias klaidas iki pirmo šio gedimo nepavykusio vykdymo. Tarpas tarp paskutinio sėkmingo vykdymo ir šio yra laikas, per kurį kažkas pasikeitė. Daugumoje mūsų taisymų tas tarpas būna apie valandą.

Štai duomenys, kuriuos n8n perduoda Error Trigger mazgui. Jie paimti iš potencialių klientų paskirstymo workflow, kurį mūsų paprašė pataisyti, jautri informacija paslėpta:

{
  "execution": {
    "id": "48213",
    "mode": "trigger",
    "retryOf": null,
    "url": "https://n8n.acme.internal/workflow/17/executions/48213",
    "error": {
      "name": "NodeApiError",
      "message": "Request failed with status code 401",
      "httpCode": "401",
      "description": "Authorization failed. Please check your credentials.",
      "node": "HTTP Request"
    },
    "lastNodeExecuted": "HTTP Request",
    "startedAt": "2026-08-19T06:14:02.771Z"
  },
  "workflow": { "id": "17", "name": "Lead routing to CRM" }
}

Svarbiausi čia trys laukai. httpCode parodo, kokio tipo tai problema. lastNodeExecuted parodo, kur vykdymas sustojo, nors klaida galėjo atsirasti ir anksčiau. startedAt duoda laiko žymą, kurią galite palyginti su viskuo, kas tą rytą vyko: diegimu, slaptažodžio pakeitimu, neapmokėta sąskaita.

Dabar palyginkite su vykdymais prieš jį ir po jo. Vykdymų sąraše tai užtrunka maždaug dvidešimt sekundžių:

Vykdymas	Pradėta	Būsena	Paskutinis mazgas	Atsakymas
48096	08-18 22:41	Success	Merge	200
48098	08-19 05:59	Success	Merge	200
48213	08-19 06:14	Error	HTTP Request	401
48214	08-19 06:31	Error	HTTP Request	401

05:59 veikė, 06:14 jau ne. Per tą ketvirtį valandos n8n viduje nieko nenutiko. Kažkas per naktį pakeitė API raktą arba saugumo politika šeštą ryto panaikino tokeno galiojimą, o workflow buvo pirmas, kuris po to bandė juo pasinaudoti.

Automatizacija nustojo veikti, nors mūsų pusėje niekas nepasikeitė

Jei sakote „workflow nustojo veikti, o aš nieko nekeičiau“, abu teiginiai gali būti teisingi. Dažniausios priežastys, nuo dažniausios:

• Baigė galioti arba buvo atšaukti prisijungimo duomenys. Google atnaujinimo tokenai, išduoti programai, kurios publikavimo būsena vis dar Testing, nustoja galioti po septynių dienų. Tai dažna skubotai sukurtų integracijų bėda, kai programa taip ir neperkeliama į Production.
• Paslaugos teikėjas nustojo palaikyti API versiją, ir senas adresas dabar atsako 410.
• Kažkas iš pardavimų komandos pervadino CRM lauką arba ištrynė pardavimų etapą. API užklausą priima, bet į neegzistuojantį lauką nieko neįrašo ir klaidos nepraneša.
• Išaugo srautas. Workflow, kuris apdorodavo 50 įrašų per dieną, pradėjo apdoroti 500 ir viršijo užklausų limitą, o n8n 429 laiko tokia pačia klaida kaip ir bet kurią kitą, nebent nurodote kitaip.
• Kažkas atnaujino n8n arba konteineris persikrovė naujame serveryje su kitu išeinančiu IP adresu, kurio nėra paslaugos teikėjo leidžiamų adresų sąraše.

Dvi iš šių priežasčių matomos pačiame n8n. Kitas reikia ieškoti kitų sistemų pakeitimų istorijoje, todėl pirmiausia klientą klausiame: kas dar nutiko rugpjūčio 19 d.?

Ką sako būsenos kodas

Atsakymo kodas atmeta pusę galimų priežasčių dar prieš atidarant bet kurį mazgą.

Kodas	Ką jis čia reiškia	Ką daryti
401	Prisijungimo duomenų nėra, jie nebegalioja arba yra neteisingi. Paslauga nežino, kas Jūs esate.	Atnaujinkite prisijungimo duomenis, prisijungdami iš naujo. Kartoti nėra prasmės, nes antras bandymas siunčia tą patį negaliojantį tokeną.
403	Paslauga žino, kas Jūs esate, bet šio veiksmo neleidžia. Pašalinta teisių sritis (scope), sumažinta licencija, pasibaigė planas arba pasikeitė leidžiamų IP sąrašas.	Prisijungus iš naujo su tomis pačiomis teisėmis niekas nepasikeis. Patikrinkite paskyros teises, tada planą.
410	Resurso nebėra, visam laikui ir sąmoningai. Paslaugų teikėjai šį kodą naudoja nebepalaikomoms API versijoms ir galutinai ištrintiems įrašams.	Perskaitykite teikėjo pakeitimų sąrašą ir perkelkite užklausą į naują versiją. Pašalinto galinio taško (endpoint) jokie pakartojimai nesugrąžins.
429	Užklausų dažnis ribojamas. Dažnai kartu siunčiama Retry-After antraštė, kurios niekas neskaito.	Kartokite su vis ilgėjančia pauze. Jei taip nutinka kasdien, duomenis reikia siųsti mažesniais paketais, o ne tiesiog kartoti.
ETIMEDOUT	Niekas neatsakė. Paslauga neveikia, veikia lėtai arba yra nepasiekiama iš Jūsų serverio.	Pakartokite, o prieš keisdami savo workflow patikrinkite teikėjo būsenos puslapį.

Yra viena išimtis, kurios ši lentelė neparodo. Daug API atsako 200, o klaidą įrašo atsakymo turinyje, todėl mazgas atrodo sėkmingas, o įrašas taip ir nesukuriamas. Jei visi vykdymai atrodo sėkmingi, o darbas vis tiek neatliekamas, tokį atvejį aprašome atskirai: workflow veikia, bet nieko nevyksta.

Keiskite vieną dalyką ir tikrinkite su prisegtais duomenimis

Atidarykite nepavykusį vykdymą, pasirinkite nepavykusį mazgą ir prisekite jo įvesties duomenis. Tada paleiskite tik tą mazgą. Jei su prisegtais duomenimis jis vėl nepavyksta, kaltas mazgas arba paslauga. Jei pavyksta, realiai ateinantys duomenys skiriasi nuo tų, kuriuos manote gaunantys. Palyginę prisegtus duomenis su sėkmingu praėjusio mėnesio vykdymu, pamatysite, kur tas skirtumas.

Prisegti duomenys taikomi tik rankiniams vykdymams. Automatiniai vykdymai jų nepaiso, todėl galite bandyti su veikiančiu workflow nekeisdami to, ką jis daro su tikrais įrašais. Todėl taip tikrinti saugu net darbo dienos rytą, kai visi laukia.

Kai priežastis aiški, iš karto sustiprinkite mazgą. Pakartojimų nustatymai yra paties mazgo nustatymuose:

{
  "name": "HTTP Request",
  "retryOnFail": true,
  "maxTries": 4,
  "waitBetweenTries": 5000,
  "onError": "stopWorkflow"
}

n8n sąsajoje galima nustatyti iki 5 bandymų ir iki 5 000 milisekundžių pauzę tarp jų, numatytosios reikšmės yra 3 ir 1 000. Jų pakanka trumpam sutrikimui, bet ne tada, kai paslauga atsigauna tik po minutės. Todėl padidinkite pauzę visur, kur workflow kreipiasi į paslaugą, turinčią būsenos puslapį. Mazguose, kurie rašo įrašus, palikite onError reikšmę stopWorkflow. Pakeitus ją į continue, nepavykęs vykdymas atrodo sėkmingas, o įrašas tiesiog neįrašomas. Sėkmingų vykdymų niekas netikrina.

Įspėjimas, kurio niekas neskaitė

Aukščiau minėtas potencialių klientų paskirstymo workflow nepavykdavo maždaug kartą per dieną iš maždaug 200 vykdymų. Įspėjimai buvo sukonfigūruoti, bet keliavo į Slack kanalą, suarchyvuotą prieš kelis mėnesius, todėl niekas nebuvo matęs nė vienos klaidos.

Tai dažniausias mūsų matomas gedimas, ir jis antras sąraše apie priežastis, kodėl automatizacijos nustoja veikti po paleidimo. Pataisymas užtrunka apie dešimt minučių. Importuokite šio puslapio viršuje esantį klaidų workflow, atidarykite kiekvieno veikiančio workflow Settings ir lauke Error Workflow pasirinkite jį. Tada apie kiekvieną nepavykusį vykdymą gausite pranešimą su workflow pavadinimu, mazgu, klaidos tekstu ir nuoroda į vykdymą ten, kur žmogus žiūri kasdien.

Dar du dalykai apie klaidų workflow, ant kurių dažnai užkliūvama. Jis nesuveikia rankiniams vykdymams, todėl mygtuku Execute Workflow neįrodysite, kad įspėjimai veikia; verčiau paleiskite tikrą vykdymą su sąmoningai sugadintais prisijungimo duomenimis. Be to, jis negali pranešti, kad neveikia visa n8n instancija, todėl faile yra ir suplanuotas gyvybės signalas (heartbeat), kurį galite nukreipti į veikimo stebėjimo įrankį.

Vykdymų duomenys saugomi ne amžinai. n8n pagal nutylėjimą juos ištrina po 336 valandų, tai yra po 14 dienų. Jei workflow sugedo prieš tris savaites ir niekas to nepastebėjo, nepavykę vykdymai, kurie būtų parodę priežastį, jau ištrinti, ir jos tenka ieškoti paslaugos teikėjo pusėje. Įspėjimas svarbus ir todėl, kad apie gedimą sužinote, kol žurnalas dar neištrintas.

Kada pagalbos nereikia

Didžioji dalis to, kas aprašyta aukščiau, yra vienos popietės darbas žmogui, kuris moka dirbti n8n redaktoriuje, ir nemažai užklausų atsakome būtent taip: susitvarkysite patys. Taisykite patys, kai:

• Klaida yra paprastas 401 viename mazge, o paskyra, kuriai priklauso prisijungimo duomenys, yra Jūsų. Prisijunkite iš naujo, sąraše dar kartą paleiskite nepavykusius vykdymus, ir viskas.
• CRM pasikeitė vieno lauko pavadinimas, ir susiejime reikia įrašyti naują.
• Workflow buvo netyčia išjungtas. Tai nutinka dažniau, nei atrodo: kas nors redaguoja veikiantį workflow ir pamiršta jungiklį. Vykdymų sąrašas tiesiog nutrūksta be jokių klaidų, nes niekas nebuvo paleista.
• Kartą per savaitę gaunate 429, o įjungus pakartojimą su penkių sekundžių pauze problema dingsta.

Kreipkitės pagalbos, kai klaidos atsiranda protarpiais ir be aiškaus dėsningumo, kai tas pats pataisymas atliktas du kartus, o workflow vėl sugedo kitaip, kai workflow išaugo iki daugiau nei 40 ar 50 mazgų ir niekas nebegali atsekti vieno įrašo kelio per jį, arba kai žmogaus, kuris jį sukūrė, nebėra. Paskutinis atvejis toks dažnas, kad parašėme atskirą straipsnį, ką daryti, kai laisvai samdomas specialistas dingo. Pusė iki šiol mūsų įvertintų taisymų prasidėjo būtent taip, o visos paskyros vis dar buvo kūrėjo vardu.

Kiek kainuoja, jei taisome mes

Pradedame nuo raštiškos diagnostikos už 450 €. Per dvi darbo dienas gaunate dokumentą, kuriame įvardyta, kas sugedo, pateikti įrodymai ir fiksuota taisymo kaina, o 450 € visa suma įskaitoma į tą kainą. Nedideli pataisymai, kaip aprašyti šiame puslapyje, kainuoja nuo 700 iki 1 400 € ir užtrunka 2-5 dienas. Jei reikia keisti workflow struktūrą, tai standartinis taisymas: nuo 1 400 iki 3 700 €, 1-2 savaitės. Viskam, ką taisome, taikoma 30 dienų garantija klaidoms, o patikimumo priemonės, kurias įdiegiame, yra tos pačios, kurias taikome savo sistemoms. Jas surašėme į AI sistemos paruoštumo kontrolinį sąrašą.

Jei tas pats workflow sugedo jau antrą kartą, prieš taisydami jį trečią kartą perskaitykite, kodėl n8n workflow nuolat lūžta. Kitu atveju atsiųskite mums vykdymo nuorodą ir klaidos tekstą per taisymo užklausos formą arba perskaitykite, kaip vyksta darbas, taisymo paslaugos puslapyje.