5 вересня 2026 року ми вирішили перевірити не сайт, а те, що мало б повідомити нам про його падіння. У нашій внутрішній документації з 17 січня 2026 року стояв рядок: чотири правила тривог, перевірка кожні 30 секунд. Частка помилок понад 5 % протягом п'яти хвилин, час відповіді (p95) довший за 2 секунди протягом 10 хвилин, вичерпаний пул з'єднань із базою, доба без жодного брифу. Звучало як захист від усього, що може статися з сайтом агенції.
Ми відкрили Grafana, де ці правила мали жити. Правил там було нуль.
Ця стаття про те, як тривоги можуть існувати лише на папері, чому такий запис переживає місяці і як приблизно за пів години з'ясувати, чи є у вашого сайту хоч одна тривога, яка справді дійде до людини.
Що ми знайшли 5 вересня
Дефектів виявилось три, і кожен окремо робив ті чотири правила марними.
Правил не було в системі. Файл із їхнім описом на сервері лежав, але його не читала жодна програма: у конфігурації системи збору метрик на нього не було посилання, а окремого сервісу, який розсилає сповіщення, не існувало взагалі. Файл просто лежав.
Правилам не було на що дивитись. Усі чотири були написані на метриках сайту: кількість HTTP-запитів, їхня тривалість, помилки, стан бази. Ці метрики оголошені в коді, тобто мають назву й опис. Але сторінки сайту не викликають функцію, яка мала б їх записувати. Ми перевірили це ще раз 17 вересня: у сховищі метрик не знайшлося жодного ряду даних ні для запитів, ні для помилок, ні для бази. Навіть якби хтось підключив файл із правилами, вони порівнювали б із порогом порожнечу.
Доставки теж не було. Єдиним каналом сповіщень у Grafana був стандартний поштовий приймач з адресою-заглушкою. Він є в кожній свіжій інсталяції й нікуди не шле.
Тобто щонайменше з середини січня до 5 вересня будь-яке падіння сайту ми могли помітити лише самі, відкривши його, — або від людини, яка не змогла ним скористатися.
Чому цього ніхто не помітив
Бо відсутня тривога виглядає так само, як спокійний день. Коли все працює, мовчать і справжні правила, і вигадані. Різниця проявляється в момент аварії, а саме тоді на документацію ніхто не дивиться.
Друга причина в тому, як виглядав сам запис. Він був конкретний: назви правил, пороги, інтервал перевірки. Такий текст не викликає сумнівів, бо схожий на опис уже зробленої роботи. Насправді це був план, записаний у формі звіту.
І третє: дашборди були. Панелі зі звичними заголовками про частоту запитів і час відповіді стояли в Grafana, і сам факт їхнього існування створював відчуття, що моніторинг є. Графіки на цих панелях були порожні, але порожній графік легко прочитати як «зараз нічого не відбувається».
Що ми поставили замість
Того ж дня ми почали з сервера, а не з сайту, бо саме сервер у нас уже падав. 2 серпня 2026 року на спільному сервері закінчилась пам'ять: процеси почали примусово вбиватися, і машину довелося перезавантажити. Про це ми дізналися не від системи, а постфактум.
Тому 5 вересня з'явилися збирачі метрик самого сервера й контейнерів, окремий дашборд і чотири правила, які цього разу існують у Grafana і шлють повідомлення в Telegram власника:
- середнє навантаження понад 8 (на восьми ядрах) упродовж 10 хвилин;
- доступної пам'яті менше 1 ГБ із 15 упродовж 5 хвилин;
- кореневий диск заповнений понад 90 % упродовж 15 хвилин;
- будь-яке джерело метрик, зокрема сам сайт, не відповідає 5 хвилин.
Кожне правило має підказку в тексті повідомлення: куди дивитися першим і що вже траплялося. У правилі про пам'ять прямо написано, що саме так починався збій 2 серпня.
Документацію переписали під те, що є насправді, а старий рядок про чотири правила лишили з поясненням, що їх ніколи не існувало. Інакше хтось знайшов би його в історії й повірив би знову.
Що показали перші 12 днів
17 вересня всі чотири правила мали стан «неактивне» і «справне»: система їх обчислює, помилок обчислення немає, умова не виконується.
Щоб зрозуміти, чи правила мовчать тому, що все гаразд, чи тому, що вони не спрацьовують, ми подивилися на самі метрики за 12 днів від запуску правил 5 вересня до 17 вересня.
- Навантаження в окремі моменти сягало 19,04, але найвище значення, яке трималося цілих 10 хвилин поспіль, було 6,79. Порогу 8 воно не досягло.
- Доступної пам'яті найменше було 4,58 ГБ. До порогу в 1 ГБ далеко.
- Диск піднімався до 93,05 %, тобто вище за поріг. Але щоразу ненадовго: за всі 12 днів набралося 16 хвилинних замірів понад 90 %, а найвище значення, що трималося всі 15 хвилин поспіль, було 88,13 %.
- Сайт як джерело метрик не відповів один раз, і це був єдиний хвилинний замір. Збирачі метрик сервера й контейнерів не пропустили жодного.
Висновок подвійний. Правила мовчали обґрунтовано: жодна умова не трималась увесь свій проміжок часу. Проте й справжнього спрацювання ще не було, тож шлях від порушеної умови до повідомлення в телефоні живим випадком поки не підтверджений.
А випадок із диском показує межу будь-якого порогу з витримкою: короткі сплески до 93 % це правило не бачить за побудовою. Ми свідомо так його налаштували, щоб не будити людину через тимчасові файли. Проте якщо диск колись заповниться повністю за ті самі кілька хвилин, тривога прийде вже після проблеми.
Як перевірити свій сайт
Для цього не треба розбиратися в коді. Потрібні доступ до системи моніторингу і пів години.
- Порахуйте правила, які існують у системі, а не в документі. У Grafana це розділ Alerting → Alert rules, в Uptime Kuma — список моніторів, у панелі хостингу — розділ сповіщень. Випишіть кожне: що перевіряє, який поріг, скільки часу має триматися порушення. Якщо список порожній або коротший, ніж вам розповідали, почніть звідси.
- Відкрийте кожне правило й подивіться, на що воно дивиться. Якщо правило рахує помилки сайту, відкрийте цей самий запит окремо й переконайтеся, що за останній тиждень у ньому взагалі є дані. Правило над порожньою метрикою мовчить не завжди однаково: у Grafana кожне правило має окреме налаштування на випадок відсутності даних, і від нього залежить, чи побачите ви звичне «в нормі», чи окремий стан «немає даних», який легко проґавити в списку. У трьох наших серверних правилах там стоїть «немає даних», у правилі про недоступну ціль — одразу тривога. Поломку порожня метрика не зловить у жодному з варіантів, тому дивіться на дані під запитом, а не на колір статусу.
- Перевірте, куди йдуть сповіщення. Подивіться список каналів доставки: пошта, Telegram, SMS. Адреса на кшталт
example@email.comабо канал, створений людиною, яка вже не працює з вами, означає, що доставки немає. - Надішліть тестове сповіщення й дочекайтеся його на телефоні. У Grafana кнопка Test є в налаштуваннях кожного каналу. Зараховується лише повідомлення, яке ви побачили, а не зелена позначка «надіслано».
- Поставте собі три запитання: якщо сайт почне віддавати помилку 500, хто про це дізнається і коли; якщо закінчиться місце на диску; якщо перестануть іти листи із заявками. На кожне має бути назва правила і людина, до якої воно прийде. Відповідь «побачимо в статистиці» означає «ніхто».
Чого ми не вирішили
Наші нові правила стежать за сервером і за тим, чи відповідає сайт. Вони не стежать за тим, чи сайт працює правильно.
Помилки 500 на окремій сторінці ми досі не бачимо, бо метрики запитів, з яких усе почалося, так і лишились порожніми. Провал відправки листа теж не дає сповіщення. 8 вересня 2026 року два листи не пішли, журнал це записав, а знайшли ми ці записи вручну, коли самі його відкрили. Історію з листами ми докладно розібрали окремо: форма каже «дякуємо», а лист не йде.
Тобто 5 вересня ми закрили найгрубішу частину: падіння сервера більше не пройде повз нас. Тиха поломка всередині сайту досі пройде. Наступний крок у нас саме такий: записувати помилки запитів і невдалі листи й ставити на них правила з тим самим каналом доставки.
Якщо вам потрібно, щоб хтось налаштував таке стеження для вашого сайту й перевірив, що повідомлення справді доходять, це робота з моніторингу доступності. Реагування на самі збої та стан сервера входять в адміністрування сервера.
Правило, яке ми винесли для себе: тривога існує, коли вона хоч раз дійшла до людини. Все інше, зокрема рядок у документації, — лише намір.
