Průvodce
Make.com scénář, který nespadne: error handling, retry a monitoring v produkci
Nastav Make.com scénáře tak, aby přežily výpadky API i špatná data: Store incomplete executions, Retry error handler s automatickým opakováním, alerty do Slacku a watchdog přes Make API. Tarify, ceny a limity ověřené k 30. 9. 2026.
⏱️
Čas
2–3 hodiny nastavení + 15 minut denně
📊
Obtížnost
Pokročilý
💰
Úspora
cca 4–8 hodin měsíčně ručního dohledu, kontroly logů a dohledávání ztracených běhů; navíc incidenty, které vůbec nenastanou, se nedají spočítat. Příplatkové náklady: 0 Kč — aktivace error handleru neúčtuje žádný kredit a watchdog spotřebuje jednotky kreditů denně.
🎯
Kroků
7
🛠️ Co budete potřebovat
Nástroje
- • Make.com účet: na vyzkoušení stačí Free (0 $, 1 000 kreditů/měsíc, minimální interval mezi spuštěními 15 minut), na produkci Core za 9 $/měsíc při 10 000 kreditech (neomezené aktivní scénáře, plánování po minutách, přístup k Make API); Pro za 16 $/měsíc přidává prioritní spouštění a fulltextové prohledávání logů spuštění. Každá akce modulu = 1 kredit. Ověřeno 30. 9. 2026 na make.com/en/pricing (měsíční platba, USD; roční platba je o 15 % a víc levnější).
- • Scénář, který už v produkci běží — ideálně s instant triggerem (webhook) nebo plánovačem a aspoň jedním modulem třetí strany (CRM, e-mail, AI, databáze).
- • Slack na alerty (Free: neomezeně kanálů, historie zpráv 90 dní; Pro 6,75 €/měsíc při roční platbě); ověřeno 30. 9. 2026 na slack.com/pricing.
- • Pro watchdog v kroku 6: API token Make (avatar vlevo dole → Profile → záložka API → Add token, scope scenarios:read) — API je dostupné od tarifu Core.
Dovednosti
- • Orientace v editoru scénářů Make: přidat modul, vytvořit connection, spustit scénář a číst výsledek běhu (základy najdeš v článku Shoptet + Make.com: kompletní průvodce integrací).
- • Představa o HTTP požadavku a JSON (pro watchdog v kroku 6 — bez programování, jen HTTP modul a mapování).
- • Přístup ke Scenario settings scénáře (práva pro úpravu v daném týmu).
V kostce
- Základy jsou dvě zatržítka ve Scenario settings: Store incomplete executions (chybný běh se uloží místo ztráty) a Process data in order (běhy nepoběží paralelně). Fungují bez jediného error handleru.
- ConnectionError, RateLimitError a ModuleTimeoutError si Make zopakuje sám s exponenciálním backoffem (1 min → 10 → 10 → 30 → 30 → 30 min → 3 h → 3 h), jakmile zapneš Store incomplete executions.
- Retry error handler přidáš pravým klikem na modul (výchozí 3 pokusy co 15 minut). Aktivace error handleru neúčtuje žádný kredit a route bez handleru může být jen Slack modul — nejjednodušší alert.
- Po třech chybných bězích v řadě Make scénář deaktivuje (Number of consecutive errors, výchozí 3); u instantních triggerů deaktivuje hned při první chybě. Warningy se do limitu nepočítají.
- Watchdog přes Make API (od tarifu Core): GET /scenarios hlídá pole isActive a dlqCount a řekne ti o problému dřív, než si ho všimneš sám.
Krok za krokem
Zapni Store incomplete executions — nastavení, které zachrání data
- Otevři scénář v editoru a v dolním panelu klikni na Scenario settings.
- Volebu Store incomplete executions přepni na Yes a nastavení ulož Save.
- Vyzkoušej to: spusť scénář na datech, o kterých víš, že modul vyhodí chybu (třeba povinné pole bez hodnoty). Běh skončí se stavem Warning a objeví se v záložce Incomplete executions.
- V Incomplete executions rozklikni uložený běh: Make tam drží chybovou zprávu, mapování a zbývající tok scénáře. Hodnotu můžeš opravit a běh dokončit tlačítkem Run.
- To samé nastav i na zbývajících produkčních scénářích — incomplete executions jsou standardně vypnuté, takže bez tohoto kroku se chybný běh prostě ztratí.
Tip
- Zapnuté incomplete executions mění všechny chyby na warningy — warningy se nepočítají do limitu po sobě jdoucích chyb, takže scénář zůstává zaplánovaný.
- Kapacita incomplete executions je sdílená pro celou organizaci podle tarifu; na Free tarifu je úložiště dat 1 MB a jeden data store, takže fronta se zaplní rychle.
- Chyba v prvním modulu scénáře se neukládá (Make nemá co uložit) — pokud ti padá trigger, přidej na něj Retry error handler, pak se uloží i tento případ.
Pozor
- Když je úložiště incomplete executions plné a máš vypnuté Enable data loss, Make scénář deaktivuje. Když máš data loss zapnuté, běhy se plánují dál, ale chybné se zahazují — vyber podle toho, co ti vadí míň.
Očekávaný výsledek
Chybný běh už se neztrácí: skončí jako warning, skončí v záložce Incomplete executions a můžeš ho opravit a dokončit ručně.
Nastav pořadí běhů a limit chyb: Process data in order + Number of consecutive errors
- Ve stejném Scenario settings přepni přepínač pokročilých nastavení a najdi volebu Number of consecutive errors. Výchozí hodnota je 3 — tolik chyb v řadě scénáře smí mít, než Make deaktivuje jeho plánování.
- U webhookových scénářů zapni Process data in order: běhy pak čekají, dokud nedoběhne předchozí a dokud nejsou vyřešené incomplete executions. Jinak Make instantní triggery pouští paralelně a na pořadí příchozích dat se nedá spolehnout.
- Rozhodni o Enable data loss (viz varování v kroku 1) podle důležitosti dat, která scénář zpracovává.
- U transakčních modulů (Data store, MySQL — poznají se podle ACID) se podívej na Auto-commit: když ho vypneš, Make commituje změny až po úspěšném dokončení celého běhu a při chybě je vrátí.
Tip
- Limit po sobě jdoucích chyb platí jen pro plánované běhy — u instantních triggerů (webhook) Make scénář deaktivuje hned při první chybě.
- Některé chyby deaktivují scénář okamžitě bez ohledu na limit: AccountValidationError (neplatný přístup), OperationsLimitExceededError a DataSizeLimitExceededError (vyčerpané limity organizace).
- Process data in order může za velké zátěže tvořit frontu — u scénářů, kde ti na pořadí nezáleží (notifikace, reporting), ho nech vypnuté.
Pozor
- Deaktivovaný scénář se sám znovu nezapne. Make pošle e-mail, když k deaktivaci dojde, ale když si ho nevšimneš, běží ti produkce naprázdno — proto v kroku 6 stavíš watchdog.
Očekávaný výsledek
Scénář má nastavená všechna bezpečnostní nastavení: ukládání chybných běhů, řízené pořadí, explicitní limit chyb a jasné rozhodnutí o data loss.
Retry error handler: automatické opakování křehkých modulů
- Vyber modul, který volá nespolehlivou službu (AI API, e-mail, CRM, databáze). Klikni na něj pravým tlačítkem a zvol Add error handler → Retry.
- V nastavení handleru přepni Automatically complete execution na Yes a nastav počet pokusů a interval — výchozí je 3 pokusy co 15 minut; pro pomalé služby dej klidně 5 pokusů po 30 minutách.
- Zkontroluj, že Store incomplete executions zůstává zapnuté — Retry handler bez něj nefunguje.
- Když necháš automatické dokončení na No, chybný běh zůstane ve frontě Incomplete executions a čeká na ruční řešení — to dává smysl u chyb, které se samy nespraví.
- Spusť testovací běh. Když modul vyhodí chybu, Make ji přemění na warning, uloží běh jako incomplete execution a podle tvého nastavení ho automaticky opakuje, dokud neprojde (nebo se pokusy vyčerpají).
Tip
- ConnectionError, RateLimitError a ModuleTimeoutError si Make sám opakuje i bez Retry handleru, jakmile máš zapnuté Store incomplete executions — s exponenciálním backoffem 1 min, 10 min, 10 min, 30 min, 30 min, 30 min, 3 h, 3 h od původního běhu.
- Retry handler umísti přímo na první modul, pokud ti padá trigger — jinak se chyba z prvního modulu neukládá (viz krok 1).
- Z jednoho scénáře Make zpracovává max 3 opakování paralelně, zbylá čekají ve frontě — při výpadku služby se fronta odbavuje v dávkách a nestřílí na API vším najednou.
Pozor
- Neopakuj chyby, které se samy nespraví: na validační chyby (chybějící povinné pole, špatný formát) má Retry handler jen 3 marné pokusy. Ty patří handleru Resume nebo Skip z kroku 4.
Očekávaný výsledek
Křehký modul má Retry handler s nastaveným počtem pokusů a intervalem; přechodný výpadek služby se sám zahojí a ty o něm maximálně najdeš warning v historii.
Resume a Skip: náhradní hodnota, nebo vědomé vynechání
- U modulů, které padají na chybějících datech, přidej pravým klikem Resume error handler a nastav náhradní hodnotu. Úřední příklad z dokumentace Make: CRM vyžaduje telefon, část lidí ho ve formuláři nevyplní — Resume dosadí náhradní hodnotu (třeba 000-000-0000) a běh doběhne.
- U modulů, kde jeden špatný záznam nemá co kazit (hromadný import, newsletter), zvaž Skip error handler: vyhodí jen chybný bundle, zbytek scénáře proběhne a běh skončí jako úspěšný.
- Commit a Rollback nech bez handleru, pokud nemáš transakční moduly (Data store, MySQL). Commit změny potvrdí a běh zastaví, Rollback vše vrátí — Rollback je mimochodem výchozí chování, když žádný handler nemáš a incomplete executions máš vypnuté.
- Celou sadu si shrň do tabulky, kterou dáš týmu: Skip (přeskočit, úspěch), Retry (zopakovat, warning), Resume (dosadit, úspěch), Commit (zapsat a zastavit, warning), Rollback (vrátit, chyba).
Tip
- Při dosazování náhradní hodnoty přes Resume přidej do dalšího modulu poznámku do dat (třeba poznámku v poli zdroj: nahrada), ať pak víš, které záznamy prošly s náhradou.
- Skip je nebezpečný tím, že běh hlásí úspěch i když chyba nastala — vždycky ho páruj s notifikací z kroku 5, jinak špatné záznamy jen tiše mizí.
Pozor
- Hlídej si, aby ti handlery nepřekrývali chyby od sebe navzájem: když na jeden modul dáš Skip a o dvě místa dál Retry, o první chybě se nikdy nedozvíš.
Očekávaný výsledek
Každý modul scénáře má promyšlenou strategii: opakovat, dosadit, přeskočit nebo zastavit — a tým ji má shrnutou na jednom místě.
Alerty: error handling route se Slack modulem a e-mailové notifikace
- Pravým klikem na kritický modul otevři Add error handler, ale místo handleru vlož do route modul Slack → Create a message. Error handling route poznáš podle tečkované čáry.
- Do zprávy namapuj název scénáře, chybovou zprávu modulu a odkaz do Make. Posílej do vyhrazeného kanálu (třeba #make-alerty), ne do DM — ať je alert vidět pro celý tým.
- Aktivace error handleru neúčtuje žádný kredit, takže alert route nemá provozní náklady.
- Zkontroluj e-mailové notifikace: Make sám posílá e-mail, když modul vyhodí neošetřenou chybu, a další e-mail, když se scénář deaktivuje opakovanými chybami. Nastavení najdeš v profilu v sekci notifikací.
- Jednu alertní route zkopíruj na všechny produkční scénáře — levnější než paralelně budovaný monitoring třetí strany.
Tip
- Route bez handleru stačí: když modul v route nevyhodí chybu, Make chybu přeskočí a běh pokračuje dál — Slack zpráva se pošle a nic se nezastaví.
- Do zprávy přidej i čas a ID běhu; při rekonstrukci incidentu z logů to ušetří hodiny.
Pozor
- Když modul uvnitř error handling route sám spadne (třeba výpadek Slacku), celý běh skončí chybou. Alertní moduly drž jednoduché a jejich výpadek hlídej watchdogem.
Očekávaný výsledek
Každá neošetřená chyba končí Slack zprávou v týmovém kanále a deaktivace scénáře přijde i e-mailem.
Watchdog přes Make API: hlídej isActive a dlqCount
- V Make si vygeneruj API token: avatar vlevo dole → Profile → záložka API → Add token, label watchdog a scope scenarios:read. Make API je dostupné od tarifu Core.
- Postav nový scénář „Watchdog“ s modulem HTTP → Make a request: GET https://eu1.make.com/api/v2/scenarios?organizationId=TVOJE_ORG_ID (zónu eu1/eu2/us1/us2 si over podle své organizace, každá zóna má vlastní token). Do hlavičky dej Authorization: Token TVUJ_TOKEN.
- Odpověď z iteruj přes Iterator a filtrem nech jen scénáře, kde isActive je false nebo dlqCount je větší než nula — dlqCount je počet nevyřešených incomplete executions.
- Za filtr přidej Slack → Create a message: název scénáře, stav a počet nevyřešených běhů, s @here, když isActive je false (deaktivace = produkce stojí).
- Naplánuj watchdog na každých 15–60 minut a opatři ho vlastním Retry handlerem — monitoring, který padá potichu, je horší než žádný.
- V odpovědi API máš k dispozici i pole executions (počet běhů), errors, operations a nextExec (příští plánované spuštění) — hodí se na týdenní přehled spotřeby.
Tip
- API si hlídá rate limit, takže watchdog drž na rozumném intervalu; pro organizaci s desítkami scénářů stačí dotaz co 15 minut.
- Než začneš panikařit, koukni na status.make.com — když má třetí strana incident, retry s backoffem za tebe dělá práci a alert si jen poznamenej.
Pozor
- Token drž jen v Make (v hlavičce HTTP modulu), nikam ho nekopíruj do sdílených dokumentů; při přístupu do více zón si vygeneruj zvláštní token pro každou.
Očekávaný výsledek
Watchdog běží na plánovači, hlídá všechny scénáře organizace a do Slacku hlásí deaktivace i rostoucí fronty incomplete executions.
Ranní rutina: historie běhů, incomplete executions a týdenní audit
- Ráno otevři Detail scénáře → historie spuštění (execution history): uvidíš stavy běhů, trvání a spotřebu kreditů. Na tarifu Pro můžeš logy prohledávat fulltextově.
- Zkontroluj záložku Incomplete executions: vyřeš to, co se nezretryovalo samo — rozklikni běh, oprav data a dokonči ho tlačítkem Run, hromadně pak po výběru více běhů.
- Jednou týdně projdi, jestli některý error handler nedrží běhy při životu zbytečně: když Retry handler opakuje tutéž chybu celý týden, jde o chybu dat, ne přechodný výpadek.
- Při podezření na výpadek služby nejprve status.make.com, pak hlášky tvojí služby (AI API mají vlastní status pages).
- Zapiš si runbook: co dělat, když scénář X spadne — kdo ho smí přepnout, kde je záloha blueprintu (scénář se dá exportovat jako blueprint JSON) a kdy eskalovat.
Tip
- Blueprint scénáře exportuj pravidelně (menu scénáře → export) — obnova z blueprintu je otázka minut, přeříkávání nastavení hodin.
- Do runbooku dej i odkaz na tento návod a na n8n verzi, pokud používáš oba nástroje: N8N AI agent, který nespadne: error handling a retry.
Pozor
- Nečisti Incomplete executions hromadným mazáním bez rozmyslu — každý smazaný běh jsou ztracená data, která už nikde jinde nejsou.
Očekávaný výsledek
Monitoring je rutina, ne hasicí akce: ranní kontrola trvá minutu, týdenní audit čtvrt hodiny a runbook přežije i dovolenou.
Výsledky implementace
❌ Před implementací
- • Scénáře běží měsíce bez dozoru. Chybu zjistíš, až ti napíše zákazník, že mu nepřišel e-mail — nebo až zjistíš, že si Make po třech chybných běhech scénář sám deaktivoval a nikdo si toho nevšiml. Ztracená data z výpadku se pak dohledávají hodiny v logách.
✅ Po implementaci
- • Přechodné chyby (RateLimitError, ConnectionError) si Make sám zopakuje s exponenciálním backoffem, kritické běhy skončí jako incomplete execution místo ztráty dat, do Slacku přijde alert z error handling route a watchdog přes Make API tě vzbudí, když se scénář deaktivuje nebo se hromadí nevyřešené běhy.
cca 4–8 hodin měsíčně ručního dohledu, kontroly logů a dohledávání ztracených běhů; navíc incidenty, které vůbec nenastanou, se nedají spočítat. Příplatkové náklady: 0 Kč — aktivace error handleru neúčtuje žádný kredit a watchdog spotřebuje jednotky kreditů denně.
Měsíční úspora
Návratnost od prvního výpadku třetí strany, který by jinak znamenal ztracená data a půldenní pátrání. Investice: odpoledne nastavení + týden pozorování záložky Incomplete executions.
Návratnost