Чому сценарій Make видає помилку і зупиняється: практичний чекліст
ConnectionError, ліміт спроб, автовимкнення сценарію після повторних помилок — покроковий чекліст діагностики Make без занурення в теорію директив.
Коротка відповідь
Якщо сценарій Make зупинився з помилкою — спочатку перевірте статус-сторінку сервісу, який видав помилку (найчастіше причина не у вас, а в тимчасовій недоступності стороннього API), потім перевірте конкретний код помилки: 401/403 — протухла авторизація, 404 — видалений чи неправильний ID ресурсу, 429 — перевищено ліміт запитів, 5xx — тимчасова проблема на боці сервісу. Лише після цього має сенс копатись у мапінгу полів усередині самого сценарію.
Якщо ви прийшли сюди після налаштування сповіщень з Google Forms у Telegram через Make і сценарій раптом перестав працювати — цей чекліст застосовний так само, незалежно від того, які саме модулі у вашому сценарії.
Крок 1 — визначте тип помилки за кодом
| Код | Що означає | Де шукати причину |
|---|---|---|
| 401 / 403 | Недійсні креденшли або недостатньо прав | Перепідключити акаунт заново (не просто "reconnect", а створити нове підключення з нуля) |
| 404 | Ресурс не знайдено | Файл/рядок/запис, на який посилається сценарій, видалено чи перейменовано |
| 429 | Перевищено ліміт запитів | Тимчасово, зазвичай минає само |
| 5xx | Проблема на боці сервісу | Не у вашому сценарії — перевірте статус-сторінку сервісу |
| ConnectionError (без HTTP-коду) | Сервіс тимчасово недоступний | Перевірте статус-сторінку конкретного додатку |
Крок 2 — для ConnectionError перевірте статус-сторінку сервісу
Офіційна рекомендація Make: якщо модуль видає ConnectionError, спершу перевірте сторінку статусу саме того сервісу, до якого підключається модуль (Google, Slack, будь-який інший) — сервіс може бути на плановому обслуговуванні чи тимчасово перевантажений, і це не проблема вашого сценарію.
Крок 3 — налаштуйте Retry з урахуванням причини
Якщо причина — тимчасова недоступність, найефективніший підхід — директива Retry, яка автоматично повторює спробу після затримки. Параметри варто підбирати під ситуацію:
- Планове обслуговування сервісу — менше спроб, довша затримка між ними (немає сенсу повторювати щохвилини, якщо сервіс лежить годинами)
- Тимчасове перевантаження — коротші проміжки, більше спроб (ситуація зазвичай минає за хвилини)
Крок 4 — увімкніть Incomplete Executions, якщо ще не увімкнено
За замовчуванням вимкнено. Без цього налаштування помилковий запуск просто відкидається без збереження — увімкнення дозволяє зберегти й повторно обробити пробіг, що впав через помилку, замість втрати даних назавжди.
Крок 5 — для сценаріїв на вебхуках — Process Data in Order
Якщо сценарій запускається вебхуком і кілька подій приходять майже одночасно під час збою, варто увімкнути Process data in order у налаштуваннях сценарію — це гарантує послідовну, а не паралельну повторну обробку черги, що зменшує ризик race condition при масовому Retry одразу кількох накопичених подій.
Важливо знати: сценарій вимикається сам
Errors (на відміну від Warnings) зупиняють поточний запуск і запускають rollback до попереднього стану. Якщо помилки повторюються з запуску в запуск, Make автоматично вимикає розклад сценарію, щоб не витрачати ресурси на завідомо провальні спроби. Це означає: якщо сценарій, що працював тижнями, раптом "мовчить" без жодного явного повідомлення — перше, що варто перевірити, це чи не вимкнувся він сам через серію помилок, а не шукати нову причину з нуля.
Warnings — легша категорія: сценарій попереджає про проблему (наприклад, спрацював error-handler і обробив помилку сам), але лишається активним і не рахується до порогу автовимкнення.
Поширені помилки при діагностиці
Одразу лізти в мапінг полів, не перевіривши код помилки. Неправильний мапінг — реальна причина, але вона на п'ятому місці в списку типових причин, не на першому. HTTP-код одразу звужує коло підозрюваних.
Реавторизовувати те саме підключення замість створення нового. Якщо реавторизація ("Reconnect") не допомагає, ефективніше видалити підключення повністю й створити заново з нуля — застаріле підключення іноді зберігає протухлі токени навіть після формальної реавторизації.
Не перевіряти права доступу окремо від самого підключення. Підключення до Google Таблиць чи Notion може бути технічно робочим, але акаунт міг втратити доступ до конкретного файлу чи папки (власник прибрав доступ, файл перенесли) — це не видно з самого статусу підключення.
Плутати чужу проблему зі своєю. Якщо помилка — 5xx чи ConnectionError, і статус-сторінка сервісу підтверджує проблему на їхньому боці — витрачати час на перебудову власного сценарію не має сенсу, треба просто зачекати й дати Retry відпрацювати.
Часті питання
Чи можна отримати сповіщення, коли сценарій автоматично вимкнувся через помилки?
Так, Make надсилає email-сповіщення власнику сценарію при автоматичному вимкненні через повторні помилки — перевірте, чи не потрапляють такі листи у спам, якщо сценарій "тихо" зупинився й ви про це не знали.
Чим Retry відрізняється від просто збільшення кількості спроб уручну?
Retry працює автоматично за розкладом, який ви одного разу налаштували, і не вимагає, щоб хтось помітив помилку й натиснув кнопку вручну — саме тому це стандартний підхід для тимчасових збоїв, а не разова "перезапустити й подивитись".
Чи потрібно вмикати Incomplete Executions для кожного сценарію?
Не обов'язково для всіх — для некритичних, малооб'ємних сценаріїв втрата одного помилкового запуску може бути прийнятною. Вмикайте там, де втрата даних (нового ліда, платежу, заявки) реально коштує грошей чи часу.
З чого почати, якщо сценарій узагалі ніколи не запускався успішно, а не просто зламався пізніше?
Це інша категорія проблем, ближча до налаштування, ніж до збою в роботі — перевірте базові речі окремо від коду помилки: чи сценарій увімкнений (Active), чи правильно обраний тригер, чи є права на всі підключені акаунти з самого початку.
Дата останньої перевірки актуальності: 28 серпня 2026 р. Поведінка помилок Make звірена з офіційною довідкою — Fix connection errors і Introduction to errors and warnings.