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

Саме так найчастіше і ламаються дрібні, але важливі бізнес-процеси. Скрипт перестав оновлювати таблицю. Парсер не підтягнув ціни. Збір лідів зупинився. А ви дізналися про це не від системи, а від клієнта, менеджера або вже з наслідків. І тут проблема не тільки в помилці. Проблема в тому, що автоматизація не вміє сказати: “У мене збій. Перевір мене.”
Чому “тиха смерть” скриптів небезпечніша за явний збій
Коли помилка очевидна, її хоча б можна швидко помітити. Але більшість Apps Script-сценаріїв працюють у фоні: за тригером, за розкладом, без відкритого інтерфейсу перед очима. Саме тому вони часто створюють ілюзію стабільності. Скрипт існує, тригер налаштований, файл на місці — значить, усе ніби має працювати.
На практиці це не так. Достатньо зміни структури сайту, формату даних, доступів до таблиці або відповіді зовнішнього сервісу — і сценарій починає падати або давати битий результат. Якщо в коді немає нормального error handling, ви не бачите цього вчасно. Автоматизація формально є, але бізнес-механізм уже не працює.
У чому суть рішення

Найпростіша страховка тут складається з трьох речей:
try...catch— щоб не дати помилці зникнути мовчки;- логування — щоб залишився слід, що саме сталося;
- Telegram-сповіщення — щоб ви дізналися про збій одразу.
На людській мові це працює так: скрипт запускається, виконує свою задачу, а якщо щось ламається — помилка ловиться, збирається в повідомлення і прилітає вам у Telegram. Не треба сидіти й гадати, “воно ще працює чи вже ні”. Система сама подає сигнал.
Якщо у вас уже є сценарії на Google Sheets і месенджерах, це дуже природно продовжує логіку інтеграції Google Sheets з Telegram та Slack, тільки тут месенджер використовується не як робочий канал, а як аварійний сигнал.
Що таке try...catch без “кодерської магії”
try...catch — це найпростіша страховка в коді. Блок try каже: “зараз я спробую виконати основну дію”. Блок catch каже: “якщо щось зламалося — не роби вигляд, що нічого не сталося, а оброби помилку”.
Саме ця конструкція і не дає скрипту “вмерти” мовчки. Без неї у вас часто буде лише факт, що щось не оновилося. З нею — вже конкретний сигнал: який саме сценарій упав, де це сталося і що писати в лог.
Як налаштувати 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, найкраще, що можна зробити сьогодні, — дати йому право “подзвонити”, коли йому погано.
А у вас був момент, коли автоматизація підвела саме тоді, коли ви були впевнені, що там усе давно працює?
Останні статті

Автоматизація погодження документів у Google Drive: статуси, версії та журнал рішень
Файли final , final new і final v7_approved не показують погоджений документ. Автоматизація погодження документів керує станами, версіями й рішеннями. Для workflow доста…

Тестування AI-автоматизацій: як перевіряти prompts і не ламати результат після оновлення
Зміна в prompt може покращити JSON і зламати зміст. Модель повертає category , але губить примітку клієнта. Тому тестування AI автоматизацій має перевіряти формат і бізн…

Автоматизація комерційних пропозицій: як зібрати Google Docs, PDF і Gmail в один процес
У комерційній пропозиції більша частина роботи повторюється: підставити компанію, контакт, послуги, ціну, строк дії та менеджера. Тому автоматизація комерційних пропозиц…

Google Apps Script security: токени, права доступу і безпечні webhook-автоматизації
Google Apps Script security часто згадують тільки після того, як автоматизація вже працює. Таблиця приймає заявки, Web App отримує webhook-и, Telegram-бот відправляє пов…

OpenAI API cost control: як рахувати токени, ставити ліміти і не отримати несподіваний рахунок
OpenAI API cost control - це не страх перед LLM, а нормальна фінансова гігієна автоматизації. Якщо модель допомагає обробляти заявки, писати summary, класифікувати зверн…

Надійність автоматизації бізнес-процесів: черги, повтори і idempotency без великої інфраструктури
Надійність автоматизації бізнес-процесів починається не з Kubernetes, RabbitMQ або складної cloud-архітектури. У малому бізнесі вона часто починається з простішого питан…