Потери от простоя сайта редко считают заранее, а зря. Час недоступности интернет-магазина с трафиком 300-500 человек в сутки выливается в конкретную сумму: упущенные заказы, слитый рекламный бюджет и десяток гневных сообщений в директе от клиентов, которые не смогли оформить заказ. Я веду техподдержку у нескольких проектов на Tilda, WordPress и кастомных SPA-сервисах и вижу одну и ту же картину: о падении сайта узнают по звонку из отдела продаж, когда цифры в CRM резко просели, хотя посчитать вероятный ущерб можно заранее и заложить деньги на мониторинг и резервный хостинг ещё на старте проекта.
Из чего складывается ущерб от простоя интернет-магазина
Упущенная выручка - только видимая часть проблемы. На практике в сумму входят пять статей сразу, а считают обычно только первую.
- Упущенные продажи за время, пока сайт недоступен или отдаёт ошибку
- Рекламный бюджет, который продолжает списываться, пока трафик из Яндекс.Директа или контекстной рекламы приходит на нерабочую страницу
- Штрафы по договору, если с заказчиком или партнёром закреплён SLA на доступность
- Работы по диагностике и восстановлению: хостинг, разработчик, иногда экстренный тариф техподдержки со срочным реагированием
- Отток части клиентов, которые ушли к конкуренту в момент падения и не вернулись даже после восстановления
На последнем пункте почти никто не считает деньги, а зря: по моим наблюдениям на проектах e‑commerce после заметного падения сайта конверсия проседает ещё на 5-10% в течение недели, потому что часть аудитории просто теряет привычку заходить именно к вам.
Формула расчёта: сколько стоит час простоя вашего сайта
Считаю по простой формуле, которая закрывает большинство случаев:
Стоимость часа простоя = Трафик в час умножить на Конверсию умножить на Средний чек, плюс рекламные расходы за этот час, плюс штраф по SLA, если он прописан в договоре.
Трафик в час беру из Яндекс.Метрики или аналога по отчёту за последние 30 дней, отдельно для рабочих часов и вечернего пика: они отличаются в разы. Конверсию и средний чек беру из CRM или отчёта эквайринга за тот же период. Рекламные расходы за час считаю по дневному бюджету кампаний, поделённому на число часов их показа, потому что деньги с рекламных площадок списываются независимо от того, работает сайт или нет.
| Тип сайта | Посетителей в час | Конверсия | Средний чек | Потенциальная выручка в час |
|---|---|---|---|---|
| Небольшой лендинг или магазин | 10 | 1,5% | 2 500 руб | 375 руб |
| Средний интернет-магазин | 30 | 2% | 3 200 руб | 1 920 руб |
| Крупный магазин или сервис | 150 | 2,5% | 4 000 руб | 15 000 руб |
Цифры в таблице показывают только потенциальную выручку, без рекламных расходов и без репутационных потерь: их плюсуют отдельно по факту.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Пример расчёта на реальных цифрах: WooCommerce, T‑Bank и зоны доставки
Возьмём реальный кейс с одним из моих клиентов: интернет-магазин на WooCommerce с эквайрингом T‑Bank, около 400 визитов в сутки, конверсия 2%, средний чек 3 200 руб. В дневные часы это 25-30 визитов в час, в вечерний пик с 18 до 22 - до 60. Падение сайта на час днём даёт упущенную выручку около 1 900 руб, а тот же час вечером обходится уже в 3 800 руб, и это без учёта рекламы.
По факту вышло дороже, потому что вместе с сайтом легла и интеграция с эквайрингом: несколько заказов клиенты успели оформить, деньги списались, а вебхук T‑Bank о статусе оплаты до магазина не дошёл. Заказы не попали в CRM, и часть клиентов пришлось разыскивать вручную через выписку банка и оформлять задним числом. Отдельная головная боль - виджет зон доставки СДЭК на чекауте: если он не отвечает, покупатель не может даже посчитать стоимость доставки и просто закрывает вкладку, даже если остальной сайт работает нормально. Такие частичные падения статистика не всегда фиксирует как простой, а выручку они режут не хуже полного отказа.
Простой лендинга на Tilda и SPA-сервиса: разная цена ошибки
На Tilda полный отказ хостинга - редкость, инфраструктура резервируется на стороне платформы. Чаще там падают кастомные скрипты: интеграция с CRM, кастомный чекаут, виджет расчёта налогов или конвертер валют. Ошибка в таком скрипте не кладёт сайт целиком, но обрывает конкретный сценарий покупки, и это незаметно в обычной аналитике посещаемости, потому что визиты продолжают идти, а заявки нет.
На кастомном SPA-сервисе или SaaS на своём хостинге риск другой: там точка отказа одна - сервер или база данных, и если она недоступна, ложится вообще всё, включая личный кабинет и API для мобильного приложения, если оно есть. Для таких проектов резервный сервер и мониторинг не роскошь, а обязательная статья бюджета с самого запуска.
Отдельно считаю потери у магазинов, которые принимают заказы ещё и через Telegram-бота на aiogram: если бот и сайт крутятся на одном VPS, при падении сервера отваливаются оба канала продаж одновременно, и убыток удваивается против расчёта только по сайту. Похожая история с автоматизацией на n8n: если сценарий, который шлёт уведомления о новых заказах в чат менеджеров, лежит на том же упавшем сервере, о проблеме узнают не по алерту, а по звонку недовольного клиента через два часа.
Скрытые издержки, которые не видно в обычной аналитике
Поисковики фиксируют повторяющиеся ошибки сервера, и при частых падениях позиции в выдаче проседают не сразу, а через 2-3 недели, когда накопится статистика по краулингу. Для сайтов с органическим трафиком это добавляет к прямым потерям ещё и стоимость возврата позиций, а SEO-продвижение окупается месяцами, а не днями.
Второй скрытый пункт - стоимость привлечения клиента заново. Если пользователь один раз не смог оформить заказ и ушёл к конкуренту, вернуть его рекламой обходится в 3-5 раз дороже, чем удержать при первом визите, даже по грубым отраслевым оценкам digital-агентств.
Для интернет-магазинов и сервисов с высокой ценой каждого часа простоя я обычно отдельно настраиваю мониторинг доступности и техническую поддержку, чтобы падение сайта фиксировалось за минуты, а не когда об этом напишет клиент в директ.
Как сократить время простоя и снизить потери
Полностью убрать риск простоя нельзя, но можно на порядок сократить время реакции и восстановления. На практике работает такой набор:
- Внешний мониторинг доступности с оповещением на телефон, а не только на почту - на рынке такой сервис у большинства студий стоит от 3 000 до 8 000 руб в месяц, для нагруженного магазина это разумная страховка
- Резервная копия перед каждым обновлением сайта или плагинов, с проверкой, что бэкап реально разворачивается, а не просто лежит в архиве
- Отдельный staging-сайт для тестирования обновлений WordPress, Tilda-скриптов и интеграций перед выкладкой на боевой домен
- Регламент реакции: кто получает алерт первым, через сколько минут подключается разработчик, куда эскалировать, если не отвечает хостинг-провайдер
- Договор техподдержки с зафиксированным временем реакции, а не разовые обращения по факту аварии
Я закладываю на техподдержку от 15 000 руб в месяц: за эти деньги в договоре фиксируется время реакции на инцидент, и клиент не ищет разработчика в панике посреди ночи, а пишет по уже известному каналу связи. Отдельно считаю восстановление сайта после заражения вирусом: цена начинается от 15 000 руб и зависит от объёма повреждений и того, сколько файлов и таблиц в базе пришлось прогонять на чистоту.
Частые вопросы
Как быстро окупается мониторинг простоя сайта?
На интернет-магазине со средним чеком от 2 000 руб мониторинг за 3 000-5 000 руб в месяц окупается одним вовремя замеченным падением сайта в рабочие часы: час простоя днём при трафике 30 визитов в час уже даёт упущенную выручку около 1 900 руб, а без мониторинга такое падение обычно замечают через 2-4 часа, а не через 5-10 минут.
Что делать в первые 10 минут после обнаружения падения сайта?
Сначала проверяю, лежит весь сайт или конкретный сценарий: касса, форма, виджет доставки. Дальше смотрю логи хостинга и статус домена и SSL-сертификата, потому что нередко причина не в коде, а в истёкшем сертификате или блокировке со стороны хостинг-провайдера. Если проблема в последнем обновлении, откатываю его первым делом, а разбор причины оставляю на потом, когда сайт уже отдаёт корректный ответ.
Входит ли простой из-за сбоя хостинга в зону ответственности разработчика?
Зависит от договора. Если хостинг выбирал и настраивал разработчик, обычно он же отвечает за реакцию на сбой в рамках техподдержки. Если хостинг ведёт сам заказчик или отдельный провайдер, разработчик обычно подключается на этапе диагностики после того, как ему сообщили о проблеме, и это стоит отдельно прописывать в договоре ещё на старте, чтобы не разбираться в этом в момент аварии.
Сколько стоит устранить простой из-за заражения сайта вирусом?
Работы по лечению сайта от вирусов и восстановлению после заражения у меня стоят от 15 000 руб, итоговая сумма зависит от того, сколько файлов заражено, затронута ли база данных и нужно ли менять пароли и ключи доступа у всех сервисов, подключённых к сайту.