Сколько стоит час простоя сайта: считаем убытки от даунтайма

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

Поэтому стоимость простоя лучше считать не одной универсальной цифрой, а моделью: прямые потери выручки, операционные расходы на восстановление, штрафы по SLA, потери лидов, репутационный эффект и недополученные будущие продажи. Для интернет-магазина и SaaS-сервиса формула будет разной, но логика одна: сначала понять, сколько денег проходит через сайт за единицу времени, а затем оценить, какая часть этого потока теряется при недоступности.

Ниже — практический способ посчитать стоимость часа простоя без фантазийных «средних по рынку». Получится не идеальная бухгалтерская точность, а рабочий диапазон, который можно использовать для выбора инфраструктуры, мониторинга, резервирования и регламентов реагирования.

Что считать простоем сайта

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

Типовые варианты простоя:

1) Полная недоступность сайта — браузер показывает ошибку соединения, таймаут, DNS_PROBE_FINISHED_NXDOMAIN, ERR_CONNECTION_TIMED_OUT, страницу хостинга или заглушку. Пользователь вообще не попадает на сайт.

2) Ошибки на критических страницах — главная открывается, но корзина, личный кабинет, оплата или API возвращают 500, 502, 503, 504. Формально аптайм выглядит приемлемо, но деньги уже теряются. Разобраться с кодами ответов поможет справочник по HTTP-статусам.

3) Частичная деградация — сайт открывается, но очень медленно. Пользователь ждёт, обновляет страницу, бросает оформление заказа. Это не «красный» даунтайм, но экономически он часто близок к нему. Диагностику таких случаев мы разбирали в статье почему сайт долго грузится.

4) Региональная недоступность — из офиса всё работает, а у части клиентов сайт не открывается из-за DNS, маршрутизации, CDN, блокировки или проблем у провайдера. Проверять такую ситуацию лучше из нескольких точек, а не только со своего компьютера.

5) Сбой отдельного сценария — например, не проходит оплата, не отправляются письма, не создаётся заказ, не работает поиск. Сайт открыт, но бизнес-процесс остановлен.

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

Из чего складывается стоимость простоя сайта

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

1) Потерянная выручка — заказы, подписки, оплаты, бронирования, донаты, пополнения баланса, которые не случились из-за сбоя. Для e-commerce это самый очевидный блок.

2) Потерянные лиды — заявки, звонки, регистрации, демо-запросы. Если сайт продаёт дорогие услуги с длинным циклом сделки, прямой выручки в момент простоя нет, но потеря одного качественного лида может стоить больше, чем десятки розничных заказов.

3) Маркетинговые расходы впустую — контекстная реклама, таргет, CPA, SEO-трафик, рассылки, партнёрские размещения. Пока кампания ведёт пользователей на недоступную страницу, бюджет сгорает без результата.

4) Операционные расходы — время разработчиков, DevOps, поддержки, менеджеров, руководителей. Даже если люди на окладе, авария вытесняет плановую работу: релизы, задачи клиентов, развитие продукта.

5) Компенсации и штрафы — возвраты, промокоды, SLA-кредиты, неустойки партнёрам, ручная обработка заказов. В B2B-сервисах этот пункт иногда важнее прямых продаж.

6) Репутационный ущерб — негативные отзывы, обращения в поддержку, потеря доверия к оплате, отказ от повторной покупки. Его сложнее посчитать, но игнорировать нельзя, особенно если надёжность — часть продукта.

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

Общая формула:

Общий ущерб = потерянная выручка + потерянная маржа будущих продаж + сгоревший маркетинг + стоимость работы команды + компенсации + оценка репутационного ущерба

Считать всё до рубля не обязательно. Для управленческого решения достаточно диапазона: например, «час простоя в рабочее время стоит от 80 000 до 150 000 ₽, а в период распродажи — до 400 000 ₽».

Базовая формула расчёта часа простоя

Начните с простого расчёта по выручке. Он не учитывает все нюансы, но даёт нижнюю границу.

Стоимость часа простоя = средняя выручка за час × доля необратимо потерянных продаж

Среднюю выручку за час лучше считать не по календарным 24 часам, а по фактическому времени активности клиентов.

Например, интернет-магазин получает 9 000 000 ₽ выручки в месяц. Основные продажи идут с 09:00 до 23:00, то есть 14 часов в день. В месяце 30 дней:

9 000 000 ₽ / (30 × 14) = 21 428 ₽ в час

Если сайт лежал в 03:00, потери могут быть ниже среднего, а если в 20:00, в пик спроса, — выше. Поэтому вводится коэффициент времени:

Потери = средняя выручка за час × коэффициент пика × доля потерянных продаж

Коэффициент пика берётся из аналитики: сравните выручку конкретного часа со средним часом. Если с 19:00 до 20:00 обычно продаётся в 1,7 раза больше, коэффициент равен 1.7.

Доля потерянных продаж тоже не всегда равна 100%: часть пользователей вернётся позже, если бренд сильный, товар редкий или заказ срочный. Но в конкурентной нише многие просто откроют другой сайт. Для осторожного расчёта используйте диапазон:

• низкий риск: 30–50% продаж потеряны безвозвратно;
• средний риск: 50–70%;
• высокий риск: 70–100%.

Если час простоя пришёлся на пик, а доля безвозвратных потерь оценена в 70%:

21 428 ₽ × 1.7 × 0.7 = 25 500 ₽

Это только выручка. При марже бизнеса 35% потерянный валовый доход:

25 500 ₽ × 0.35 = 8 925 ₽

Для планирования полезно считать обе величины: выручку — чтобы понимать масштаб оборота, маржу — чтобы сравнивать с расходами на инфраструктуру и мониторинг.

Как посчитать потери для разных типов сайтов

Одинаковый час простоя по-разному влияет на интернет-магазин, медиа, SaaS и корпоративный сайт. Ниже — модели, которые можно адаптировать под свою экономику.

1) Интернет-магазин — расчёт идёт от заказов.

Потери = среднее число заказов в час × средний чек × доля потерянных заказов

Магазин получает 240 заказов в день, активные продажи идут 12 часов, средний чек — 3 500 ₽:

240 / 12 = 20 заказов в час

При часовом простое и потере 60% заказов:

20 × 3 500 ₽ × 0.6 = 42 000 ₽ выручки

Добавьте рекламный бюджет за этот час. Если контекст и таргет тратят 120 000 ₽ в день при 16 часах активной рекламы:

120 000 ₽ / 16 = 7 500 ₽

Итого прямой ущерб — около 49 500 ₽, без учёта поддержки, возвратов и репутации.

2) SaaS и онлайн-сервисы — пользователь может не платить прямо в момент сбоя, но простой влияет на отток, поддержку и SLA.

Потери = SLA-компенсации + стоимость команды + риск оттока клиентов

Час простоя не означает потерю часовой доли MRR, но если сбои повторяются, клиент может уйти — поэтому важно учитывать влияние на SLO/SLA. Разницу между этими показателями мы разбирали в статье что такое SLI, SLO и SLA.

Пример: у сервиса 200 B2B-клиентов, средний платёж — 15 000 ₽ в месяц. Сбой длился 2 часа: прямых отмен нет, но поддержка получила 80 обращений, инженеры потратили 10 человеко-часов, двум крупным клиентам дали скидку. Стоимость такого простоя — не «два часа MRR», а сумма компенсаций, трудозатрат и повышенного риска оттока.

3) Лидогенерационный сайт — считайте стоимость потерянной заявки.

Потери = визиты за час × конверсия в лид × доля потерянных лидов × ценность лида

Ценность лида считается через среднюю сделку и конверсию отдела продаж:

Ценность лида = средняя маржа сделки × конверсия лида в сделку

Сайт получает 600 визитов в день, основная активность — 10 часов, конверсия в заявку — 4%, средняя маржа сделки — 60 000 ₽, в сделку превращается 15% лидов.

Визитов в час: 600 / 10 = 60 Лидов в час: 60 × 0.04 = 2.4 Ценность лида: 60 000 ₽ × 0.15 = 9 000 ₽

Если час простоя забрал 80% лидов:

2.4 × 0.8 × 9 000 ₽ = 17 280 ₽

4) Медиа и контентные проекты — потери идут через рекламу, подписки, партнёрские интеграции и SEO.

Потери = рекламная выручка за час + недополученные подписки + штрафы по размещениям

Если модель зависит от просмотров, используйте RPM/CPM и обычный трафик за час. Для партнёрских публикаций учитывайте обязательства по показам и размещениям.

5) Внутренние порталы и B2B-кабинеты — прямой выручки может не быть, но есть простой сотрудников или клиентов.

Потери = число затронутых пользователей × средняя стоимость часа × длительность сбоя

Если 40 сотрудников не могут работать 1,5 часа, а полная стоимость часа сотрудника для компании — 1 200 ₽:

40 × 1 200 ₽ × 1.5 = 72 000 ₽

Это не «виртуальные» деньги: задачи переносятся, клиенты ждут, сроки сдвигаются.

Почему средняя стоимость часа обманывает

Средняя цифра удобна для презентации, но опасна для решений: у большинства сайтов нагрузка и выручка распределены неравномерно.

1) Время суток и день недели — час ночью и час вечером могут отличаться в разы; для B2B критичнее рабочее время клиентов, для интернет-магазина — вечер и выходные, для доставки — обед и вечер. Пик может приходиться на разные дни недели, поэтому считать только по месячной выручке без разбивки — значит сгладить реальный риск.

2) Сезонность — распродажи, праздники, зарплатные дни, рекламные запуски, вебинары, релизы, медийные публикации. Час простоя во время крупной кампании может стоить дороже, чем целый день в спокойный период.

3) Этап воронки — падение лендинга, каталога, корзины и платёжной страницы стоит по-разному. Если не работает только блог, ущерб один; если не проходит оплата — совсем другой.

4) Канал трафика — органика, брендовый спрос, контекст, партнёрские переходы и рассылка по-разному возвращаются после сбоя. Пользователь из рассылки может открыть письмо позже, а клик из рекламы чаще теряется сразу.

Полезно вести таблицу сценариев:

Такая таблица помогает принимать решения быстрее: если час простоя в пике стоит 150 000 ₽, а отказоустойчивость, резервирование и мониторинг обходятся заметно дешевле, инвестиция легко обосновывается.

Как время обнаружения влияет на убытки

Длительность простоя складывается не только из времени ремонта, но и из времени обнаружения и реакции:

Общее время сбоя = время до обнаружения + время до начала работ + время восстановления + время проверки

Если сайт упал в 14:00, команда узнала об этом в 14:25, начала разбираться в 14:35 и восстановила работу в 15:05, бизнес потерял не 30 минут ремонта, а 65 минут доступности.

Здесь мониторинг напрямую влияет на деньги: если проверка сайта выполняется раз в 5 минут, сбой обнаруживается быстрее, чем при ручной проверке «когда кто-то заметит». Statuser проверяет сайт с заданным интервалом и уведомляет о сбое, сокращая именно эту невидимую часть простоя.

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

Не менее важны алерты: если уведомления приходят в общий чат, где их никто не читает, формально мониторинг есть, но время до принятия аварии в работу (MTTA) остаётся высоким. Хорошая схема реагирования отвечает на вопросы:

• кто получает алерт;
• кто дежурит;
• что делать в первые 5 минут;
• когда эскалировать;
• где лежит чеклист восстановления;
• как понять, что сервис действительно восстановлен.

Если алертов слишком много, команда начинает их игнорировать — это отдельная проблема, alert fatigue. Практичные подходы к настройке уведомлений описаны в статье как строить алерты, которые не раздражают.

Что включить в свой калькулятор простоя

Чтобы не считать ущерб каждый раз с нуля, заведите таблицу — в Google Sheets, Excel, Notion или внутренней BI-системе.

Минимальный набор полей:

1) Период расчёта — месяц, неделя, день. Лучше брать последние 3–6 месяцев и отдельно учитывать сезонность.

2) Выручка или ценность лидов — фактическая выручка, количество заказов, средний чек, лиды, конверсия в сделку, маржа.

3) Активные часы продаж — не календарные 720 часов в месяце, а время, когда реально идёт спрос.

4) Коэффициенты по времени — ночь, рабочее время, вечерний пик, выходные, распродажи.

5) Доля безвозвратных потерь — сколько пользователей не вернутся после сбоя.

6) Маркетинговые расходы — бюджет в час по активным каналам.

7) Стоимость команды — средняя ставка инженерной, продуктовой и support-команды, участвующей в аварии.

8) Компенсации и штрафы — скидки, возвраты, SLA-кредиты, ручная обработка.

9) Тип сбоя — полная недоступность, ошибка оплаты, деградация, региональная проблема, сбой API.

10) Фактическое время инцидента — начало, обнаружение, начало работ, восстановление, закрытие.

Итоговая строка:

Ущерб = (выручка_в_час × коэффициент_пика × доля_потерь) + маркетинг_в_час + трудозатраты + компенсации

Для лидогенерации замените выручку на ценность лида:

Ущерб = лиды_в_час × ценность_лида × доля_потерь + маркетинг_в_час + трудозатраты

Для SaaS добавьте отдельные поля: затронутые клиенты, условия SLA, обращения в поддержку, потенциальный отток.

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

Как использовать расчёт для технических решений

Расчёт стоимости простоя нужен не для отчёта ради отчёта — он помогает определить, сколько разумно тратить на снижение риска.

1) Выбрать уровень SLA — если час простоя стоит 10 000 ₽, достаточно простого хостинга и базового мониторинга; если 300 000 ₽ — нужна архитектура с резервированием, аварийными регламентами и регулярными проверками восстановления. О том, сколько минут простоя допускают разные уровни доступности, — статья про SLA 99.9% и 99.99%.

2) Обосновать резервирование — второй сервер, реплика базы, балансировщик, CDN, резервный DNS и бэкапы стоят денег, но сравнивать их нужно не с нулём, а с ожидаемым ущербом от простоя.

3) Настроить мониторинг по критическим сценариям — проверять только главную страницу недостаточно. Для магазина критичны каталог, корзина, авторизация, оплата; для API — ключевые эндпоинты, ошибки, latency, зависимые сервисы. Мониторинг должен отвечать на вопрос: может ли пользователь выполнить целевое действие?

4) Сократить время восстановления (MTTR) — его уменьшают не только опытные инженеры, но и документация: runbook, доступы, шаблоны команд, порядок отката релиза, контакты провайдеров.

5) Проверить бэкапы и восстановление — наличие резервной копии не равно возможности быстро подняться. Если база восстанавливается 6 часов, это тоже часть стоимости простоя. Для PostgreSQL можно начать с инструкции по автоматическому бэкапу, но затем обязательно протестировать восстановление.

6) Подготовить план аварии — кто принимает решение об откате, кто пишет клиентам, кто отключает рекламу, кто проверяет оплату после восстановления. Когда сайт уже лежит, придумывать процесс поздно. Базовый чеклист — в материале что делать, если упал сайт.

В этой схеме Statuser закрывает один конкретный участок: регулярно проверяет сайт и уведомляет о сбое, сокращая время между «сайт уже недоступен» и «команда начала реагировать» — но не заменяет архитектурную отказоустойчивость.

Как уменьшить стоимость будущих простоев

Убрать простой полностью нельзя, но можно снизить вероятность, длительность и ущерб.

1) Разделите критические и некритические части — если блог недоступен, это неприятно, если не работает оплата — это авария. Мониторинг, алерты и дежурства должны отражать реальную критичность.

2) Делайте безопасные релизы — откат, feature flags, canary или blue-green deployment снижают риск положить весь сайт одной выкладкой. Особенно это важно для изменений в авторизации, платежах, корзине, миграциях базы.

3) Следите за зависимостями — DNS, SSL-сертификаты, CDN, платёжный провайдер, почтовый сервис, база данных, очереди. Сайт может быть жив, а бизнес-процесс остановится из-за внешнего компонента.

4) Документируйте типовые аварии — 502 после деплоя, переполненный диск, истёкший сертификат, зависшая база, ошибка миграции, исчерпание пула соединений. После каждого инцидента добавляйте в runbook симптомы, команды диагностики и порядок восстановления.

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

6) Отключайте платный трафик при аварии — если сбой затянулся, рекламные кампании лучше временно поставить на паузу или перенаправить на рабочую страницу — это простое действие снижает прямые потери.

7) Проводите разборы без поиска виноватых — цель постмортема не наказать, а найти системные причины: почему сбой случился, почему его поздно заметили, почему восстановление заняло столько времени, что предотвратит повторение.

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

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

FAQ

Сколько стоит час простоя сайта в среднем?
Средней полезной цифры нет. Для одного сайта это тысячи рублей, для другого — сотни тысяч. Считайте от своей выручки, лидов, рекламных расходов и длительности сбоя.

Нужно считать потерянную выручку или прибыль?
Лучше считать обе величины. Выручка показывает масштаб потока, прибыль или маржа — реальный финансовый эффект. Для решений об инфраструктуре обычно полезнее маржа плюс операционные расходы.

Если сайт упал ночью, ущерба нет?
Не обязательно. Ночью могут идти заказы, работать клиенты из других часовых поясов, выполняться интеграции, индексация, фоновые задачи. Но коэффициент потерь часто ниже, чем в пик.

Как быстро понять, что простой действительно закончился?
Проверьте не только главную страницу, но и ключевой сценарий: авторизация, каталог, корзина, оплата, API. После восстановления стоит ещё посмотреть логи, ошибки и метрики, чтобы убедиться, что проблема не повторяется.