Uptime сайта: что это и как считать
«У нас аптайм 99,9%» звучит внушительно, пока не посчитать, сколько это в реальных минутах простоя. Разбираем, что такое uptime, как его считают на практике и почему одна и та же цифра может означать очень разные вещи в зависимости от того, кто и как её измерял.
Что такое uptime
Uptime — доля времени, в течение которого сайт или сервис был доступен и отвечал корректно, за выбранный период. Считается в процентах: отношение времени безотказной работы к общему времени наблюдения. Обратная величина — downtime, суммарное время простоя.
Формула простая, но дьявол в деталях: что считать «доступен», за какой период мерить и кто это измеряет. Разные ответы на эти три вопроса дают разные цифры для одного и того же сайта.
Сколько минут простоя скрывается за процентом
| Uptime | Простой в месяц | Простой в год |
|---|---|---|
| 99% | ~7 часов 18 минут | ~3 дня 15 часов |
| 99,9% | ~43 минуты | ~8 часов 46 минут |
| 99,95% | ~22 минуты | ~4 часа 23 минуты |
| 99,99% | ~4 минуты | ~53 минуты |
Разница между 99% и 99,9% на бумаге выглядит незначительной, а по факту — это разница между «сайт лежал почти сутки за месяц суммарно» и «сайт лежал меньше часа». Для интернет-магазина с постоянным трафиком это разница в конкретных потерянных заказах.
Что считать простоем — не всегда очевидно
Полная недоступность — сайт не отвечает вовсе, это считают простоем всегда и все.
Медленный ответ — сайт формально отвечает, но за 15–20 секунд вместо привычной секунды. Многие системы мониторинга это в простой не засчитывают, хотя для посетителя разница ощущается как «сайт не работает».
Частичная деградация — главная страница открывается, а корзина или форма заказа отдаёт ошибку. Проверка одной только доступности главной этого не поймает вовсе.
Хостинг-провайдер обычно гарантирует доступность своей инфраструктуры — серверов и сети. Это не учитывает падения из-за ошибок в коде сайта, истёкшего сертификата, проблем с DNS или сбоя внешнего API, от которого зависит сайт. Цифра в договоре с хостером почти всегда выше, чем реальный аптайм сайта глазами посетителя.
Как считать честно
Точность подсчёта напрямую зависит от того, как часто проверяют доступность. Проверка раз в час пропустит пятиминутное падение сайта почти наверняка — она просто не окажется в нужный момент. Чем короче интервал между проверками, тем точнее итоговая цифра отражает реальность, а не удачное совпадение расписания проверки с моментом, когда сайт был жив.
Второй важный момент — точка наблюдения. Проверка с одного сервера не отличит локальную проблему у себя в сети от того, что сайт реально недоступен для большинства посетителей: сайт может быть недоступен из одного региона или у одного провайдера, оставаясь рабочим для остальных.
Пруфен считает uptime по факту опроса из нескольких точек мониторинга одновременно — падение засчитывается, когда сайт недоступен для большинства локаций, а не для одной случайной сети. Минимальный интервал проверки доступности — 2 минуты, поэтому короткие сбои не теряются между проверками. История по каждой проверке доступна в отчётах. Уведомления приходят на Email, в Telegram, в Макс или звонком.
Частые вопросы
Какой uptime считается хорошим для обычного сайта? Для большинства проектов ориентир — 99,9% и выше. Для интернет-магазина с высокой посещаемостью и e-commerce-нагрузкой к этому добавляется требование к скорости реакции на сбой, а не только к самой цифре.
Учитывается ли плановое обслуживание в простое? Зависит от методики: часть провайдеров исключает заранее анонсированные технические окна из расчёта SLA, часть — нет. Для посетителя сайта разницы нет: недоступность есть недоступность независимо от причины.
Можно ли посчитать uptime задним числом без мониторинга? Только приблизительно — по логам сервера или отчётам хостинга, и то не всегда полно. Без независимого внешнего наблюдения короткие сбои, особенно на уровне сети или DNS, обычно остаются незамеченными полностью.
Стоит ли публиковать свой uptime публично? Для B2B-сервисов и SaaS это распространённая практика доверия — публичная страница статуса. Для обычного сайта смысла меньше, но сама метрика полезна внутри команды, чтобы объективно оценивать надёжность инфраструктуры, а не полагаться на ощущения.