Когда владелец сайта слышит «uptime 99,9%», это звучит надежно. На практике один процент доступности без контекста почти ничего не объясняет: важно понимать, что именно проверялось, как быстро заметили сбой, сколько длился простой и какие страницы были недоступны. Один и тот же сайт может формально «работать», но отдавать ошибку на странице оплаты, медленно отвечать из части регионов или показывать техническую заглушку вместо каталога.
В этой статье разберем, что такое uptime сайта простыми словами, как считать доступность без самообмана и почему автоматический мониторинг полезнее редкой ручной проверки.
Что такое uptime сайта
Uptime сайта — это доля времени, когда сайт доступен для пользователей и корректно отвечает на запросы. Обычно его выражают в процентах за выбранный период: день, неделю, месяц или год.
Простая формула выглядит так:
```text uptime = время доступности / общее время наблюдения * 100% ```
Если сайт был доступен весь месяц, uptime близок к 100%. Если часть времени сайт не открывался, отдавал критическую серверную ошибку или не отвечал по таймауту, этот период считается простоем.
Но в реальной жизни важна не только формула. Нужно заранее договориться, что именно считается доступностью:
- главная страница открылась и вернула успешный HTTP-код;
- ключевая страница загрузилась без редиректа на ошибку;
- SSL-сертификат действителен, браузер не показывает предупреждение;
- DNS отвечает корректно, домен резолвится у внешних клиентов;
- страница отвечает быстрее разумного порога, а не зависает до таймаута.
Без таких правил uptime превращается в красивую цифру, которая может не совпадать с пользовательским опытом.
Что считать простоем, а что нет
Самая частая ошибка — считать простоем только полное падение сайта. Для владельца бизнеса проблема шире: пользователь не может выполнить нужное действие. Поэтому недоступность бывает разной.
Полный простой
Сайт не открывается совсем: браузер показывает ошибку соединения, DNS не находит домен, сервер не отвечает или возвращает 502, 503, 504. Такой сбой легко заметить, но если проверять сайт вручную, можно узнать о нем слишком поздно.
Частичная недоступность
Главная страница работает, а раздел каталога, корзина, личный кабинет или форма заявки отдают ошибку. Для мониторинга одной главной страницы такой сайт может выглядеть доступным, хотя часть клиентов уже не может оставить заказ.
Медленный ответ
Иногда сайт не падает полностью, но отвечает настолько долго, что пользователь закрывает вкладку. Формально HTTP-код может быть успешным, но с точки зрения продаж и SEO это уже инцидент, который нужно видеть в истории проверок.
Ошибка содержимого
Сайт возвращает код 200, но вместо нужной страницы показывает заглушку, пустой экран, сообщение CMS об обслуживании или страницу авторизации. Поэтому для важных страниц полезно проверять не только код ответа, но и ожидаемый текст на странице.
Почему проценты uptime могут вводить в заблуждение
Процент доступности выглядит убедительно, но он скрывает важные детали.
Например, если сайт был недоступен несколько коротких периодов ночью, бизнес может почти ничего не потерять. Если такой же суммарный простой случился днем во время рекламной кампании, ущерб будет совсем другим. В обоих случаях процент за месяц может выглядеть одинаково, но смысл инцидента разный.
Еще один пример: мониторинг проверяет только главную страницу раз в несколько минут. Между проверками сайт может успеть упасть и восстановиться. Короткий сбой не попадет в отчет, но пользователи в этот момент могли увидеть ошибку. Поэтому важно смотреть не только на общий uptime, но и на частоту проверок, историю статусов, время ответа и список проверяемых URL.
Для владельца сайта полезнее вопрос не «какой у нас процент», а «как быстро мы узнаем о проблеме и можем ли понять, что именно сломалось».
Как посчитать простой на простом примере
Возьмем месяц как период наблюдения. Если мониторинг видит, что сайт был недоступен суммарно 45 минут, расчет можно сделать так:
```text общее время месяца в минутах - минуты простоя = время доступности время доступности / общее время месяца * 100% = uptime ```
Важнее не сама арифметика, а качество исходных данных. Перед расчетом проверьте:
- какой период берется: сутки, неделя, календарный месяц или последние 30 дней;
- какие страницы участвовали в проверке;
- были ли исключены плановые технические работы;
- считались ли таймауты и ошибки SSL простоем;
- как обрабатывались единичные сетевые ошибки проверки.
Если этих правил нет, разные люди могут получить разные значения uptime для одного и того же сайта.
Какие проверки нужны для честной картины
Одна проверка главной страницы лучше, чем полное отсутствие мониторинга. Но для сайта, который приносит заявки или продажи, стоит смотреть шире.
HTTP-статус и редиректы
Проверяйте, что сайт возвращает ожидаемый код ответа и не уводит пользователя в неожиданную цепочку редиректов. Важно отдельно контролировать версии с www и без www, HTTP и HTTPS, если они используются в ссылках или рекламе.
DNS и домен
Если домен не резолвится, сайт может быть исправен на сервере, но недоступен для клиентов. Поэтому DNS-проблемы нужно отделять от ошибок хостинга и CMS.
SSL-сертификат
Просроченный или неверно настроенный SSL может сделать сайт недоступным для части пользователей даже при рабочем сервере. Для владельца это такой же инцидент, как падение страницы.
Время ответа
История времени ответа помогает увидеть деградацию до полного сбоя. Если сайт постепенно отвечает все медленнее, команда может успеть проверить хостинг, базу данных, кэш или внешние API до того, как появятся массовые ошибки.
Ключевые страницы
Для интернет-магазина это каталог, карточка товара, корзина и оформление заказа. Для сервисного сайта — форма заявки, страница цен, личный кабинет или API-метод, без которого клиент не может завершить действие.
Как Web-Puls помогает не спорить о цифрах
Чтобы не проверять сайт вручную, можно настроить автоматический мониторинг в Web-Puls. Он регулярно проверяет доступность сайта и помогает быстрее узнать, если страница перестала открываться, начала отвечать ошибкой или стала слишком медленной.
Практический подход такой: добавьте главную страницу, затем вынесите в отдельные проверки самые важные URL. Если сайт зависит от SSL, DNS, редиректов или формы заявки, эти участки лучше контролировать отдельно. Тогда при инциденте проще понять, проблема в домене, сертификате, сервере, CMS или конкретной странице.
Важно, что мониторинг нужен не только для красивого процента uptime. Он дает историю: когда начался сбой, когда сайт восстановился, как менялось время ответа и были ли повторные проблемы. Эта история помогает разговаривать с хостингом, разработчиком или подрядчиком предметно.
Чеклист владельца сайта
Перед тем как оценивать uptime, ответьте на несколько вопросов:
- какие страницы для бизнеса критичны;
- какой HTTP-код считается нормальным для каждой страницы;
- какой таймаут уже нужно считать проблемой;
- кто получает уведомление о падении;
- что делать, если сайт недоступен только в одном регионе;
- где хранится история инцидентов;
- кто отвечает за DNS, SSL, хостинг и CMS.
Если ответы записаны заранее, сбой проходит спокойнее. Команда не тратит первые минуты на спор, упал сайт или «это только у кого-то одного», а сразу проверяет понятный список причин.
Вывод
Uptime сайта — полезная метрика, если за ней стоят понятные правила проверки. Считать нужно не только полный простой, но и ошибки ключевых страниц, SSL, DNS, таймауты и резкое ухудшение времени ответа. Процент доступности без истории инцидентов мало помогает владельцу: он не объясняет, когда началась проблема, кого она затронула и что нужно исправить.
Лучший практический шаг — настроить регулярную проверку сайта и заранее определить, какие события считаются сбоем. Тогда uptime становится не абстрактной цифрой в отчете, а рабочим инструментом контроля доступности.