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

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

Почему расчёт потерь важен

Без количественной оценки простоя невозможно:

• Обосновать бюджет на мониторинг, резервирование и инфраструктуру
• Приоритизировать задачи по надёжности
• Коммуницировать с руководством и инвесторами на языке цифр
• Оценивать эффективность внедрённых мер (сокращение MTTR, предотвращение инцидентов)

Расчёт не требует сложной аналитики. Достаточно базовых данных из бухгалтерии и аналитики. Точность ±20% — уже полезный результат для принятия решений.

Базовые формулы расчёта

Прямые потери выручки

Для бизнеса, где сайт напрямую генерирует доход, базовая формула проста:

Потери = (Выручка за период / Часы в периоде) × Часы простоя

Пример для интернет-магазина с выручкой 5 000 000 ₽/месяц:

5 000 000 ₽ / (30 дней × 24 часа) = 6 944 ₽/час

Один час простоя в среднем обходится в ~7 000 ₽. Но это усреднённая оценка. Реальные потери зависят от времени суток, дня недели и сезона.

Учёт неравномерности трафика

Трафик и конверсии распределены неравномерно. Пиковые часы (обычно 12:00–21:00 по местному времени) приносят 60–70% выручки. Если сайт падает в пик, потери выше среднего:

Потери_пик = Потери_средние × Коэффициент_пика (1.5–2.0)

Для того же магазина час простоя в пиковое время может стоить 10 000–14 000 ₽.

Формула с учётом конверсии

Более точный расчёт требует данных аналитики:

Потери = Посетители_за_период × Конверсия × Средний_чек × (Часы_простоя / Часы_в_периоде)

Пример:

• 100 000 посетителей в месяц
• Конверсия 2%
• Средний чек 3 000 ₽
• 2 часа простоя

100 000 × 0.02 × 3 000 × (2 / 720) = 16 667 ₽

Расчёт по типам бизнеса

E-commerce и интернет-магазины

Для интернет-магазинов потери наиболее прозрачны — каждая минута простоя равна упущенным заказам.

Показатель	Малый магазин	Средний магазин	Крупный маркетплейс
Выручка/мес	500 000 ₽	5 000 000 ₽	50 000 000 ₽
Потери/час (средние)	694 ₽	6 944 ₽	69 444 ₽
Потери/час (пик)	1 400 ₽	14 000 ₽	140 000 ₽
1% даунтайма/мес (7.2 ч)	5 000 ₽	50 000 ₽	500 000 ₽

Дополнительные факторы для e-commerce:

1. Потеря привлечённого трафика. Если вы платите за рекламу (Яндекс.Директ, VK Реклама), трафик во время простоя уходит к конкурентам. Стоимость привлечения клиента (CAC) теряется полностью.

2. Корзины и отложенные заказы. Пользователи, добавившие товар в корзину, могут не вернуться. Исследования показывают, что 70–80% брошенных корзин не конвертируются при повторном визите.

3. Репутационные потери. Негативные отзывы, обсуждения в соцсетях, переход к конкурентам — сложно оценить количественно, но для брендовых магазинов это существенно.

SaaS и подписочные сервисы

Для SaaS-продуктов формула сложнее: выручка приходит по подписке, а не по каждой транзакции. Но простой влияет на несколько метрик.

Прямые потери:

Потери = (MRR / 720) × Часы_простоя × Доля_активных_пользователей

MRR (Monthly Recurring Revenue) — месячная выручка от подписок. Доля активных пользователей — те, кто реально использует продукт в данный момент (обычно 20–40%).

Пример: SaaS с MRR 1 000 000 ₽, 30% активных пользователей, 4 часа простоя:

(1 000 000 / 720) × 4 × 0.3 = 1 667 ₽ прямых потерь

Прямые потери для SaaS часто ниже, чем для e-commerce. Но косвенные — выше:

Фактор	Влияние
Churn (отток)	Клиенты корпоративного сегмента могут расторгнуть контракт при нарушении SLA
Компенсации	По SLA часто предусмотрены кредиты (credit) за простой
Репутация	Для B2B один публичный инцидент может стоить крупного контракта
Поддержка	Рост нагрузки на саппорт, overtime сотрудников

Расчёт SLA-компенсаций:

Типичный SLA для SaaS: 99.9% аптайма. При нарушении — возврат части оплаты.

99.9% = допустимо 43.2 минуты простоя в месяц
99.99% = допустимо 4.32 минуты простоя в месяц

При 99.5% аптайма (3.6 часа простоя) многие контракты предусматривают 10–25% кредита за месяц. Для MRR 1 000 000 ₽ это 100 000–250 000 ₽ прямых потерь.

Медиа и контент-сайты

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

Формула для рекламной модели:

Потери = RPM × (Трафик_за_час / 1000) × Часы_простоя

RPM (Revenue Per Mille) — доход с 1000 показов. Трафик за час — среднее число посетителей.

Пример: Сайт с 50 000 визитов в день, RPM 150 ₽:

50 000 / 24 = 2 083 визита/час
150 × (2 083 / 1000) × 2 = 625 ₽ за 2 часа простоя

Для крупных медиа с миллионами визитов потери исчисляются десятками и сотнями тысяч рублей за час простоя в пиковое время.

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

Корпоративные сайты и лендинги

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

1. Потеря лидов. Каждый визит — потенциальный клиент. Стоимость лида (CPL) × количество визитов за период простоя.

2. Репутация. Клиент или партнёр, не сумевший открыть сайт, может усомниться в надёжности компании.

3. Внутренние процессы. Если на сайте размещены формы заявок, каталоги, калькуляторы — сотрудники не могут работать.

SLA: расчёт целевого аптайма

Service Level Agreement определяет допустимый уровень простоя. Переведём проценты в минуты:

Аптайм	Простой в месяц	Простой в год
99%	7.2 часа	3.65 дня
99.5%	3.6 часа	1.8 дня
99.9%	43.2 минуты	8.76 часа
99.95%	21.6 минуты	4.38 часа
99.99%	4.32 минуты	52.6 минуты

Как выбрать целевой SLA:

1. Оцените стоимость часа простоя по формулам выше.
2. Сравните с стоимостью обеспечения более высокого аптайма (резервирование, CDN, премиум-хостинг).
3. Учтите ожидания клиентов. B2B-клиенты часто требуют 99.9%+. Для лендинга может быть достаточно 99%.

Пример расчёта окупаемости мониторинга:

Стоимость Uptime Monitor — 50 токенов в месяц. Допустим, это 500 ₽. Если один предотвращённый инцидент (раннее обнаружение проблемы) экономит 2 часа простоя для магазина с выручкой 5 млн/мес — экономия 14 000 ₽. Окупаемость 28:1.

Скрытые и отложенные потери

Не все потери видны сразу.

SEO-последствия

Поисковые системы обходят сайты регулярно. Если в момент обхода Googlebot получает 5xx:

• Страница может временно выпасть из индекса
• Краулинговый бюджет сокращается
• При повторных инцидентах — снижение позиций

Восстановление позиций занимает недели или месяцы. Стоимость — упущенный трафик за весь период.

Доверие пользователей

Исследования показывают: 88% пользователей не вернутся на сайт после неудачного опыта. Один инцидент может стоить не только прямых потерь, но и постоянного оттока части аудитории.

Стоимость устранения

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

Практический калькулятор

Сводная формула для быстрой оценки:

Потери = Базовые_потери × K_время × K_тип × K_дополнительно

Где:

• Базовые потери — выручка за период / часы в периоде
• K_время — 1.0 (ночь), 1.5 (день), 2.0 (пик)
• K_тип — 1.0 (e-commerce), 0.3 (SaaS), 0.1 (медиа/реклама)
• K_дополнительно — 1.2–1.5 (SEO, репутация, поддержка)

Чек-лист для расчёта потерь вашего сайта:

1. Соберите данные: месячная выручка, трафик, конверсия, средний чек
2. Рассчитайте базовую стоимость часа простоя
3. Определите пиковые часы и коэффициент
4. Умножьте на типичную длительность инцидента (без мониторинга — 30–60 минут, с мониторингом — 5–15 минут)
5. Добавьте 20–50% на косвенные потери

Частые ошибки в расчётах

Ошибка 1: Игнорирование косвенных потерь

Прямая выручка — только часть. SEO-последствия, репутация, отток клиентов, стоимость срочного устранения — добавляют 20–50% к базовому расчёту.

Ошибка 2: Использование только средних значений

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

Ошибка 3: Забывать про сезонность

Чёрная пятница, конец квартала, праздники — стоимость простоя в эти периоды в 2–5 раз выше. Планируйте инфраструктуру с учётом пиков.

Ошибка 4: Не учитывать время обнаружения

Без мониторинга вы узнаёте о проблеме от пользователей — через 30–60 минут или больше. С мониторингом — за 5–10 минут. Разница в длительности простоя напрямую влияет на потери.

Ошибка 5: Считать «маленький» бизнес незначительным

Даже при выручке 100 000 ₽/месяц час простоя стоит ~140 ₽. Четыре инцидента в год по 2 часа — 1 120 ₽. При стоимости мониторинга 500 ₽/мес окупаемость есть. И это без учёта репутационных потерь.

Инструменты мониторинга

Расчёт потерь — первый шаг. Второй — минимизация рисков.

Uptime Monitor — мониторинг доступности сайта с проверками каждые 5 минут. Мгновенные уведомления в Telegram при падении. Чем раньше вы узнаете о проблеме, тем меньше длительность простоя и потери.

SSL Monitor — мониторинг срока действия SSL-сертификатов. Истечение сертификата — частая причина «внезапного» даунтайма. Заблаговременное предупреждение за 14–30 дней позволяет обновить сертификат без простоя.

Регулярный мониторинг не предотвращает технические сбои, но сокращает время обнаружения с часов до минут. При стоимости часа простоя 7 000 ₽ разница между 60 и 5 минутами — 6 400 ₽ сэкономленных за один инцидент.

Реальные кейсы и сценарии

Кейс 1: Интернет-магазин электроники

Выручка 12 млн ₽/месяц, конверсия 1.5%, средний чек 8 000 ₽. Сайт упал в субботу в 14:00 на 2 часа — пиковое время.

Расчёт:

• Средние потери: 12 000 000 / 720 = 16 667 ₽/час
• Коэффициент пика: 1.8 (выходной, день)
• Суммарные потери: 16 667 × 2 × 1.8 × 1.3 (косвенные) ≈ 78 000 ₽

Дополнительно: 15 заказов в корзине не завершены, часть пользователей ушла к конкурентам. Реальные потери могли превысить 100 000 ₽.

Кейс 2: SaaS для малого бизнеса

MRR 500 000 ₽, 50 корпоративных клиентов. Простой 6 часов в рабочий день. SLA 99.9%, при нарушении — 10% кредита.

Расчёт:

• Прямые потери (25% активных): (500 000 / 720) × 6 × 0.25 ≈ 1 042 ₽
• SLA-кредит: 500 000 × 0.1 = 50 000 ₽
• Риск оттока: 2–3 клиента рассматривают расторжение (оценка 30 000–90 000 ₽)

Итого: 50 000–140 000 ₽. Прямые потери малы, но косвенные существенны.

Кейс 3: Новостной портал

200 000 визитов в день, RPM 200 ₽. Сайт упал во время важного события на 45 минут.

Расчёт:

• Средний трафик: 200 000 / 24 = 8 333 визита/час
• Пиковый трафик во время события: × 2.5 = 20 833 визита/час
• Потери: 200 × (20 833 / 1000) × 0.75 ≈ 3 125 ₽

Но главная потеря — трафик ушёл к конкурентам навсегда. Часть аудитории не вернётся. Оценка долгосрочного ущерба — 50 000–100 000 ₽.

Сезонность и особые периоды

Стоимость простоя резко возрастает в определённые периоды:

Период	Коэффициент	Примечание
Чёрная пятница, 11.11	3–5×	Пик продаж для e-commerce
Конец месяца/квартала	1.2–1.5×	B2B активнее
Праздники	1.5–2×	Рост трафика
Ночь	0.3–0.5×	Минимальная активность
Выходные (B2B)	0.5–0.7×	Снижение активности

При планировании инфраструктуры и мониторинга учитывайте: инцидент в Чёрную пятницу для магазина с выручкой 5 млн/мес может стоить 100 000+ ₽ за час.

ROI мониторинга: расчёт окупаемости

Мониторинг окупается, если предотвращает инциденты или сокращает их длительность.

Формула:

ROI = (Потери_предотвращённые × N_инцидентов_в_год) / Стоимость_мониторинга_за_год

Пример: Стоимость Uptime Monitor 500 ₽/мес = 6 000 ₽/год. Без мониторинга среднее время обнаружения — 45 минут, с мониторингом — 5 минут. Экономия 40 минут на инцидент. При 4 инцидентах в год и стоимости 7 000 ₽/час:

Экономия = 7 000 × (40/60) × 4 = 18 667 ₽
ROI = 18 667 / 6 000 ≈ 3.1

Мониторинг окупается в 3 раза. При большем количестве инцидентов или более высокой стоимости простоя — ROI выше.

Интеграция с бизнес-процессами

Расчёт потерь — первый шаг к системной работе с надёжностью:

1. Бюджетирование. Зная стоимость простоя, можно обосновать расходы на резервирование, CDN, премиум-хостинг.

2. Приоритизация. Если час простоя стоит 70 000 ₽, круглосуточная поддержка DevOps окупается. Если 700 ₽ — достаточно мониторинга с уведомлениями.

3. Коммуникация с руководством. «Сайт падал 3 раза в год по 2 часа — мы теряли 42 000 ₽. Мониторинг за 6 000 ₽/год сократит потери на 80%» — понятный аргумент.

4. SLA с подрядчиками. Если хостинг или разработчик гарантирует 99.9%, при нарушении можно требовать компенсацию. Расчёт потерь — основа для переговоров.

Рекомендации

1. Рассчитайте свою стоимость простоя по формулам в этой статье. Хотя бы приблизительно.
2. Документируйте расчёт — пригодится для обоснования бюджета на мониторинг и инфраструктуру.
3. Настройте мониторинг до первого серьёзного инцидента. Узнавать о проблемах от клиентов — худший сценарий.
4. Определите целевой SLA исходя из типа бизнеса и ожиданий клиентов.
5. Проводите постмортемы после инцидентов — фиксируйте реальную длительность, причины и потери. Данные улучшат будущие расчёты.
6. Учитывайте сезонность при планировании инфраструктуры и оценке рисков.
7. Рассчитайте ROI мониторинга для вашего проекта — это поможет принять решение о внедрении.

Шаблон расчёта для презентации

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

Слайд 1: Текущая ситуация

• Тип сайта и выручка/трафик
• Типичная длительность инцидентов (по данным постмортемов или оценка)
• Частота инцидентов в год

Слайд 2: Расчёт потерь

• Формула и исходные данные
• Стоимость часа простоя (средняя и пиковая)
• Суммарные потери за год без улучшений

Слайд 3: Предложение

• Стоимость мониторинга/инфраструктуры
• Ожидаемое сокращение потерь (MTTR, предотвращение)
• ROI и срок окупаемости

Слайд 4: Следующие шаги

• Конкретные действия и сроки

Такой подход переводит технический вопрос о мониторинге в бизнес-язык, понятный руководству.

Заключение

Расчёт потерь от даунтайма — не академическое упражнение, а практический инструмент. Он помогает обосновать инвестиции в мониторинг, приоритизировать задачи по надёжности и оценивать эффективность внедрённых мер. Формулы в этой статье применимы к большинству типов сайтов. Начните с приблизительной оценки, уточняйте данные по мере накопления статистики инцидентов. Даже грубый расчёт лучше, чем решение «вслепую».

Краткая справка: формулы

Тип бизнеса	Базовая формула
E-commerce	(Выручка/мес / 720) × Часы × K_пик
SaaS	(MRR / 720) × Часы × Доля_активных + SLA_кредит
Медиа	RPM × (Трафик_час / 1000) × Часы
Лендинг	CPL × Визиты_за_период_простоя

Коэффициент пика: 1.0 (ночь) — 2.0 (пик). K_дополнительно (SEO, репутация): 1.2–1.5.

Следующий шаг после расчёта — внедрение мониторинга. Uptime Monitor и SSL Monitor сокращают время обнаружения инцидентов с часов до минут, что напрямую снижает потери.

Подробнее о настройке мониторинга — в статье «Мониторинг доступности сайта: зачем нужен и как настроить». О действиях при падении сайта — в «Что делать когда сайт упал: план действий».