Сколько стоит студии узнать о падении сервера от клиента

Студия сдала сайт, получила деньги и ушла. Через полгода у клиента лёг сервер — и звонят не хостеру, а вам: вы же «делали сайт».

Дальше начинается самое дорогое в этой работе. И считают его почти всегда неправильно.

Почему студия узнаёт последней

После сдачи проект выпадает из поля зрения: задач по нему нет, в трекере он закрыт, в календаре его нет. Сервер работает — значит, о нём никто не думает.

Единственный, кто смотрит на этот сервер каждый день, — клиент. Он и заметит первым. Не потому что внимательнее, а потому что он там живёт.

Что на самом деле в этом часе

Час незнания состоит из трёх строк, и студии обычно считают одну.

Час команды. Разработчик и менеджер, оторванные от плановой работы, умноженные на длительность инцидента. Это та строка, которую называют все.

Извинение. Скидка на следующий месяц поддержки, бесплатная доработка, «давайте мы вам ещё вот это сделаем». Редко меньше стоимости самого простоя.

Потеря. Вероятность, что клиент уйдёт, умноженная на его годовой чек. После одного инцидента она невелика. После второго, о котором клиент снова узнал первым, — уже нет.

Арифметика на условных числах

Подставьте свои, но форма такая:

Теперь та же арифметика, но вы узнали первым. Час команды остаётся — чинить всё равно вам. Извинение превращается в сообщение «у вас упал сервер, уже поднимаем», и оно бесплатно. Вероятность потери падает: клиент видел, что вы смотрите.

Разница между двумя расчётами и есть цена незнания. У каждой студии она своя, но почти всегда выходит больше, чем стоит любой мониторинг.

Что можно поднять самим за вечер

Честно: чтобы узнавать раньше клиента, продукт не обязателен.

• Внешняя проверка доступности — простейший вариант делается бесплатным сервисом за десять минут: адрес, интервал, уведомление в чат.
• Свой Uptime Kuma на любой машине — вечер работы, дальше почти не требует внимания.
• cron с curl и отправкой в Telegram — полчаса, если у вас уже есть бот.

Любой из трёх закрывает главный разрыв: вы узнаёте о падении не от клиента. Это девяносто процентов пользы.

Чего это не решает

Проверка снаружи говорит «не отвечает». Она не говорит, почему.

Между «сайт не открывается» и «выяснили, что случилось» лежит второй разрыв, и он длиннее первого: доступа к серверу нет или он у уволившегося, что там развёрнуто — никто не помнит, последний выкат делал не тот, кто сейчас на связи.

Именно поэтому мы у себя завели инцидент как объект проекта, а не как уведомление в чат: у падения должна быть карточка, к которой прикреплены сервер, выкат и документы, — иначе через полгода восстановить картину нельзя, и второй такой же инцидент разбирается с нуля.

Что из этого следует

Мониторинг обычно продают как «спокойствие». Это неправда: спокойствия он не даёт, падения от него не прекращаются.

Он даёт порядок, в котором вы узнаёте новость. Первым — вы, а не клиент. И считать его окупаемость нужно не по цене подписки, а по той разнице в арифметике выше: скидка, которую вы не дали, и клиент, который не начал искать другую студию.

---

У нас проверки доступности идут снаружи, метрики — агентом с самой машины, а инцидент открывается сам и становится карточкой в проекте. Как это устроено — Мониторинг доступности.