Найнеприємніший збій в автоматизації — не той, який “красиво впав”. А той, який стався тихо, без сигналу, і кілька днів жив собі окремим життям, поки ви були впевнені, що все працює.

Коли скрипт «втомився»: Налаштування моніторингу та сповіщень про помилки в Telegram
Коли скрипт «втомився»: Налаштування моніторингу та сповіщень про помилки в Telegram

Саме так найчастіше і ламаються дрібні, але важливі бізнес-процеси. Скрипт перестав оновлювати таблицю. Парсер не підтягнув ціни. Збір лідів зупинився. А ви дізналися про це не від системи, а від клієнта, менеджера або вже з наслідків. І тут проблема не тільки в помилці. Проблема в тому, що автоматизація не вміє сказати: “У мене збій. Перевір мене.”

Чому “тиха смерть” скриптів небезпечніша за явний збій

Коли помилка очевидна, її хоча б можна швидко помітити. Але більшість Apps Script-сценаріїв працюють у фоні: за тригером, за розкладом, без відкритого інтерфейсу перед очима. Саме тому вони часто створюють ілюзію стабільності. Скрипт існує, тригер налаштований, файл на місці — значить, усе ніби має працювати.

На практиці це не так. Достатньо зміни структури сайту, формату даних, доступів до таблиці або відповіді зовнішнього сервісу — і сценарій починає падати або давати битий результат. Якщо в коді немає нормального error handling, ви не бачите цього вчасно. Автоматизація формально є, але бізнес-механізм уже не працює.

У чому суть рішення

У чому суть рішення
У чому суть рішення

Найпростіша страховка тут складається з трьох речей:

  • try...catch — щоб не дати помилці зникнути мовчки;
  • логування — щоб залишився слід, що саме сталося;
  • Telegram-сповіщення — щоб ви дізналися про збій одразу.

На людській мові це працює так: скрипт запускається, виконує свою задачу, а якщо щось ламається — помилка ловиться, збирається в повідомлення і прилітає вам у Telegram. Не треба сидіти й гадати, “воно ще працює чи вже ні”. Система сама подає сигнал.

Якщо у вас уже є сценарії на Google Sheets і месенджерах, це дуже природно продовжує логіку інтеграції Google Sheets з Telegram та Slack, тільки тут месенджер використовується не як робочий канал, а як аварійний сигнал.

Що таке try...catch без “кодерської магії”

try...catch — це найпростіша страховка в коді. Блок try каже: “зараз я спробую виконати основну дію”. Блок catch каже: “якщо щось зламалося — не роби вигляд, що нічого не сталося, а оброби помилку”.

Саме ця конструкція і не дає скрипту “вмерти” мовчки. Без неї у вас часто буде лише факт, що щось не оновилося. З нею — вже конкретний сигнал: який саме сценарій упав, де це сталося і що писати в лог.

Як налаштувати Telegram-бота для алертів

Як налаштувати Telegram-бота для алертів
Як налаштувати Telegram-бота для алертів

Для такого сценарію не потрібна складна бот-архітектура. Достатньо найпростішого Telegram-бота, створеного через @BotFather. Після цього у вас буде:

  • токен бота;
  • ваш chat_id;
  • можливість надсилати собі повідомлення прямо з Apps Script через HTTP-запит.

Тобто Telegram тут виступає як легкий канал сповіщень. Без окремого мобільного застосунку, без складного моніторингового сервісу і без зайвої інфраструктури.

Базова логіка: ловимо помилку і шлемо її в Telegram

Ось простий робочий каркас для Apps Script:

function runMainScript() {
  try {
    const scriptName = 'Оновлення цін';
    const spreadsheetUrl = SpreadsheetApp.getActiveSpreadsheet().getUrl();

    // ===== ОСНОВНА ЛОГІКА =====
    // Наприклад:
    // updatePrices();
    // collectLeads();
    // parseSite();
    // syncData();

    Logger.log(scriptName + ': виконано успішно');

  } catch (error) {
    const scriptName = 'Оновлення цін';
    const spreadsheetUrl = SpreadsheetApp.getActiveSpreadsheet().getUrl();

    const message =
      '🚨 Помилка в автоматизації
' +
      'Скрипт: ' + scriptName + '
' +
      'Помилка: ' + error.message + '
' +
      'Таблиця: ' + spreadsheetUrl + '
' +
      'Час: ' + new Date().toLocaleString('uk-UA');

    sendTelegramAlert(message);

    Logger.log(message);
    throw error;
  }
}

function sendTelegramAlert(text) {
  const token = PropertiesService.getScriptProperties().getProperty('TELEGRAM_BOT_TOKEN');
  const chatId = PropertiesService.getScriptProperties().getProperty('TELEGRAM_CHAT_ID');

  const url = 'https://api.telegram.org/bot' + token + '/sendMessage';

  UrlFetchApp.fetch(url, {
    method: 'post',
    payload: {
      chat_id: chatId,
      text: text
    },
    muteHttpExceptions: true
  });
}

Цей приклад не “чарівний”, але він робить головне: якщо процес ламається, ви не втрачаєте цей момент. Помилка не зависає десь у фоновому логі. Вона одразу виходить назовні.

Як зробити, щоб скрипт працював сам, поки ви спите

Якщо це Apps Script, найпростіший варіант — запускати сценарій за розкладом. Наприклад, раз на годину або раз на 15 хвилин — залежно від того, наскільки критичний процес.

Тут важливо зрозуміти: тригер — це не “моніторинг” сам по собі. Тригер лише запускає код. Моніторинг з’являється в той момент, коли код уміє розпізнати збій, записати його в лог і відправити вам сигнал. Без цього у вас є просто автоматичний запуск, але немає автоматичного контролю.

Що має бути в повідомленні про помилку

Найгірший алерт — це той, який нічого не пояснює. Якщо вам у Telegram прилітає просто “сталася помилка”, такий сигнал дратує, але не допомагає.

Нормальне повідомлення має містити:

  • назву скрипта;
  • текст помилки;
  • пряме посилання на таблицю або процес;
  • час збою.

За бажанням можна додати ще назву функції, в якій це сталося, або короткий context block — наприклад, з яким саме джерелом даних працював сценарій.

Реальний кейс автора: коли збій уже стався, а бізнес ще про це не знає

Я почав жорстко додавати такі алерти після кількох дуже приземлених ситуацій. Один із моїх робочих Apps Script-сценаріїв формально існував, тригер був активний, але корисного результату ланцюжок уже не давав через зовнішню зміну в даних. Найгірше було не те, що він упав. Найгірше — що про це не було сигналу.

Проблема виявилася не в момент збою, а значно пізніше, коли вже довелося вручну перевіряти, з якого саме часу дані пішли некоректно. Після цього я почав майже в усі важливі автоматизації додавати просту зв’язку: try...catch + лог + Telegram-повідомлення.

Практичний ефект дуже відчутний: замість сценарію “можемо випадково помітити завтра або через кілька днів” реакція на збій скоротилася до кількох хвилин після помилки. І саме в цей момент автоматизація перестає бути лотереєю.

Де тут справжня вигода для бізнесу

Це не про “ще одну технічну фішку”. Це про контроль.

На практиці така дрібна доробка дає:

  • менше сліпих зон у важливих процесах;
  • швидшу реакцію на збій;
  • кращий uptime для ваших бізнес-механізмів;
  • менше втрат через тихі поломки.

І що важливо — це не потребує великого бюджету. Вам не треба окремий DevOps-контур або складна система моніторингу, щоб хоча б перестати втрачати помилки в тиші.

Коли цього вже мало

Якщо у вас 1–3 критичні сценарії на Google Sheets або Apps Script, Telegram-алерти закривають задачу дуже добре. Але якщо автоматизацій стає багато, вони залежать одна від одної, працюють із кількома зовнішніми сервісами і вже впливають на продажі або сапорт, тоді логічно рухатись далі — до централізованого логування, окремих webhook-нотифікацій і сервісів на кшталт мікросервісів на Node.js для Google Workspace.

Тобто Telegram-бот для помилок — це не “фінальна архітектура”, а дуже хороша перша лінія захисту.

Практичний підсумок

Автоматизація без error handling — це лотерея. Вона або працює, або вже давно ні, просто ви ще про це не знаєте.

Тому якщо у вас є хоча б один важливий скрипт на Google Sheets або Apps Script, найкраще, що можна зробити сьогодні, — дати йому право “подзвонити”, коли йому погано.

А у вас був момент, коли автоматизація підвела саме тоді, коли ви були впевнені, що там усе давно працює?