Что такое uptime сайта и как честно считать 99,9 %

Uptime сайта — доля времени, в течение которого сайт отвечал так, как должен: отдавал ожидаемый код, укладывался в таймаут, показывал нужную страницу, а не заглушку. Всё остальное — downtime, простой. «99,9 % за месяц» означает, что в сумме сайт не работал не дольше 43 минут; «99 %» — уже больше семи часов. Само число ничего не значит, пока не договорились, что считать простоем, как часто и откуда измерять. Увидеть, как сайт выглядит снаружи прямо сейчас, можно без регистрации — проверка доступности сайта с нескольких точек покажет код ответа и время загрузки из Москвы, Казани, Хельсинки, Мадрида и Милана.

Uptime — не строка в договоре с хостером и не вывод команды uptime на сервере (она показывает время с последней перезагрузки, сайт при этом может лежать неделю). Это результат непрерывных внешних измерений, которые даёт мониторинг доступности сайта: система по расписанию запрашивает страницу с разных точек, фиксирует каждый отказ как инцидент с началом и концом и складывает их длительность. Процент честен ровно настолько, насколько честно настроены проверки.

Формула: uptime, downtime и период

uptime (%) = (T − D) / T × 100

T — длительность периода, D — суммарный простой за период

Пример. Период — 30 дней, это 43 200 минут. За месяц было три инцидента: 12, 25 и 6 минут, итого D = 43 минуты. Uptime = (43 200 − 43) / 43 200 × 100 = 99,9005 %. SLO в 99,9 % выполнен, но с запасом в 12 секунд.

Период надо называть явно. «30 дней» и «календарный месяц» — разные вещи: в 31-дневном месяце 44 640 минут, и те же 0,1 % — это уже 44,6 минуты. Для года берут 365 дней (525 600 минут), и в високосный год бюджет простоя вырастает на 1,44 минуты для 99,9 %.

Есть два способа получить D, и они дают разные числа:

• По времени инцидентов. Начало — момент первой неуспешной проверки, конец — первая успешная. Сумма длительностей и есть D. Это то, что показывают статус-страницы.
• По доле проверок. uptime = успешных / всех. При интервале 5 минут одна неуспешная проверка «весит» 5 минут, хотя реальный сбой мог длиться 40 секунд.

Второй способ считается в одну строку по выгрузке результатов:

$ head -3 checks.csv
2026-09-01T00:00:00Z,200,0.183,ok
2026-09-01T00:01:00Z,200,0.176,ok
2026-09-01T00:02:00Z,502,0.021,fail
$ awk -F, '{n++} $4=="ok"{ok++} END{printf "%.4f %%\n", ok/n*100}' checks.csv
99.9053 %

Оба способа сходятся, когда интервал мал по сравнению с длительностью инцидентов: расхождение — не больше одного интервала на инцидент. При интервале в минуту и трёх сбоях по 10–40 минут это до 3 минут — единицы процентов бюджета 99,9 %; при интервале 15 минут три коротких сбоя по минуте засчитаются как 45 минут — больше всего бюджета.

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

Расчёт для суток (1440 минут), 30 дней (43 200 минут) и года (525 600 минут):

Что это значит на практике:

• 99 % — по полчаса простоя каждые два дня. Для магазина заметно в выручке, для визитки — терпимо.
• 99,9 % — один аварийный перезапуск сервера плюс пара коротких сбоев в месяц. Достижимо на одном VDS с мониторингом, который будит ночью.
• 99,95 % — 21 минута. Обновление ядра с перезагрузкой уже съедает заметную часть бюджета, если не вынесено в окно плановых работ.
• 99,99 % — 4 минуты в месяц. Это меньше, чем нужно человеку, чтобы прочитать уведомление, зайти по SSH и перезапустить сервис. Без резервирования (второй сервер, балансировщик, автоматический failover) этот уровень не держится.
• 99,999 % — 26 секунд. Уровень телеком-оборудования; для одного сайта это маркетинговая цифра, а не цель.

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

Uptime, SLI, SLO и SLA: метрика, цель и обещание

Эти слова часто путают, хотя они отвечают на разные вопросы:

Uptime — один из SLI; рядом обычно живут SLI по скорости («95 % запросов быстрее 1 секунды») и по ошибкам («доля 5xx меньше 0,1 %»). SLO превращает SLI в порог и даёт полезную сущность — бюджет ошибок: при цели 99,9 % за 30 дней у вас есть 43 минуты. Потратили 35 на сбой после деплоя — оставшиеся 8 минут диктуют, что до конца месяца рискованные выкатки лучше отложить.

SLA — это SLO, записанный в договор, обычно с запасом: внутри команда целится в 99,95 %, клиенту обещает 99,9 %. Главное в SLA — не процент, а методика. В типовом SLA хостинга простой считается по мониторингу самого провайдера, с момента открытия тикета клиентом, без плановых работ и без проблем «на стороне клиента». Три этих оговорки легко превращают реальные 98 % в отчётные 99,95 %. Поэтому свой uptime надо считать самостоятельно, а не брать из отчёта той стороны, которая платит компенсацию за его нарушение.

Что считается простоем, а что нет

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

Это простой:

• соединение не устанавливается: connection refused, таймаут, DNS не резолвится;
• ошибка TLS — истёкший сертификат или неполная цепочка. Для браузера это полноценный «сайт не работает», хотя сервер жив;
• ответ 5xx: 500, 502, 503, 504 — по RFC 9110 это ошибки сервера;
• ответ 200, но без ключевой фразы: заглушка хостинга, страница «ведутся работы», пустой шаблон при упавшем бэкенде.

Это не простой, а отдельная метрика:

• Деградация. Страница отдаётся за 8 секунд вместо 300 мс. Формально сайт работает, фактически половина посетителей ушла. Смешивать это с uptime нельзя — число перестаёт что-либо значить. Правильнее отдельный порог по времени ответа в мониторе (например, дольше 5 секунд — сбой) или отдельный SLO по скорости.
• Частичная недоступность. Главная открывается, оформление заказа — нет. Uptime считается на монитор, поэтому у каждого критичного сценария свой монитор: /, /cart, /api/health, страница входа. Общий uptime сервиса не выше худшего из компонентов (если сбои не совпадают по времени — ещё ниже), и уж точно не среднее.
• Ответы 403 и 429. Чаще всего это WAF, антибот-защита или лимит запросов заблокировали робота мониторинга. Это ошибка измерения, не сбой: IP-адреса точек добавляют в белый список (у Нотифарио их выдают по запросу — см. страницу о роботе). Ответ 401 означает, что монитор смотрит на закрытый авторизацией адрес — ему нужны учётные данные или другой URL.

Плановые работы — отдельная история. В «сыром» uptime они входят: для посетителя в этот момент сайт лежал. В SLA их обычно исключают при условии предупреждения заранее (типовые 24–72 часа) и оговорённого окна. Честный вариант — показывать оба числа и отмечать окно работ на статус-странице. Технически на время работ стоит отдавать 503 с заголовком Retry-After: поисковики воспримут это как временную недоступность и не тронут индекс (если работы не затянутся на дни), а мониторинг однозначно отличит плановое от аварии.

Для nginx режим работ включается созданием файла-флага:

location / {
    if (-f /var/www/maintenance.flag) {
        add_header Retry-After 1800 always;
        return 503;
    }
    proxy_pass http://backend;
}

Ошибки измерения, из-за которых uptime врёт

Одна точка проверки

Скрипт на том же сервере или в той же сети при падении канала ложится вместе с сайтом. Данных о сбое нет — в отчёте 100 %. Обратная ситуация: единственная точка стоит у провайдера с плохим пирингом до вашего хостинга и раз в день ловит таймаут — в отчёте лишний час простоя, которого пользователи не видели. Минимум — две-три точки в разных сетях, из них хотя бы две там, где живёт аудитория. Для рунета это точки в России плюс одна снаружи — она отличает проблему сайта от проблемы российского сегмента сети или блокировки.

Редкий интервал

Проверка раз в 15 минут пропускает десятиминутный сбой целиком (uptime 100 %) или ловит его одной-двумя проверками и засчитывает как 15–30 минут (uptime занижен вдвое-втрое). Погрешность одного инцидента — до одного интервала на начало и одного на конец. Для цели 99,9 % за месяц (43 минуты) интервал 5 минут при пяти инцидентах даёт погрешность до ±25 минут — больше половины бюджета. Ориентир: для 99,9 % — интервал 1–2 минуты, для 99,99 % — 1 минута с нескольких точек, и всё равно с оговоркой о погрешности.

Ложные срабатывания

Потерянный пакет, сброшенное балансировщиком соединение, таймаут 3 секунды на пике нагрузки — без подтверждения каждый такой глюк становится инцидентом длиной в интервал. Защита: подтверждение сбоя минимум с двух точек, порог «две неуспешные проверки подряд», таймаут 10–15 секунд, а не 3. Обратная сторона: подтверждение сдвигает начало инцидента на интервал-другой. Чтобы не занижать простой, при разборе инцидента учитывайте эту поправку: реальное начало — первая неуспешная проверка, на интервал-другой раньше подтверждения. Если монитор фиксирует начало по подтверждению, прибавляйте один-два интервала к длительности.

«Сайт отвечает 200, но не работает»

Самая коварная ошибка: мониторинг «по коду ответа» её не видит.

• nginx отдаёт статическую заглушку с кодом 200, пока бэкенд лежит;
• кэш отдаёт устаревшую копию при мёртвом бэкенде — так работает proxy_cache_use_stale в nginx, и для главной страницы это благо, а для корзины — тихий сбой;
• SPA отдаёт index.html с 200 на любой URL, а API за ним отвечает ошибками;
• CMS показывает «ошибка соединения с базой данных» в нормальном шаблоне с кодом 200.

Лечится двумя вещами. Первая — проверка ключевой фразы: фрагмент, который есть только на живой странице (название товара, «Корзина», часть футера). Вторая — отдельный /health, который реально трогает зависимости и отдаёт 503, если хотя бы одна недоступна:

$ curl -s -w '\nhttp=%{http_code}\n' https://example.ru/health
{"status":"ok","db":"ok","redis":"ok","queue_lag_s":2}
http=200

Как считать честно: методика на одной странице

1. Запишите определение сбоя для каждого монитора: URL, ожидаемый код (обычно 200, для редиректов — 301/302 с нужным Location), ключевая фраза, таймаут, порог времени ответа.
2. Три точки в разных сетях, две из них — в регионе аудитории. Подтверждение сбоя минимум с двух точек и двумя проверками подряд.
3. Интервал — одна минута для внешних сайтов и API, 5 минут — для внутренних сервисов и тяжёлых проверок. Чем выше цель в девятках, тем короче интервал.
4. Считайте по времени инцидентов, а не по доле проверок; помните, что подтверждение сдвигает зафиксированное начало на интервал-другой позже реального. Период называйте явно: «30 дней» или «календарный месяц».
5. Плановые работы отмечайте отдельно и показывайте uptime с ними и без. Для читателя статус-страницы оба числа полезны.
6. Публикуйте. Uptime, который никто не видит, никого не дисциплинирует. Публичная статус-страница с историей за 90 дней собирается из тех же мониторов и снимает с поддержки вопрос «а у вас всё работает?». Для сайта или README подойдёт бейдж с uptime за 30 дней — одна строка HTML.
7. Сверяйте с серверными логами, но помните про асимметрию: 5xx в access.log подтверждают инцидент, а отсутствие записей не доказывает, что сайт работал — когда сервер недоступен, он ничего не пишет.

Доля 5xx за сутки по access.log (формат combined, код ответа — 9-е поле):

$ awk '$9 ~ /^5/ {e++} {n++} END {printf "5xx: %d из %d (%.3f %%)\n", e, n, e/n*100}' \
    /var/log/nginx/access.log
5xx: 1842 из 2913377 (0.063 %)

Если uptime за месяц вышел 99,7 % вместо 99,9 % — это повод открыть список инцидентов, а не менять методику: там почти всегда два-три однотипных, и лечить нужно их.

Коротко

• Uptime — доля времени, когда сайт отвечал по заданным критериям; формула: (период − простой) / период × 100. Период называйте явно.
• 99,9 % за 30 дней — это 43 минуты простоя, 99,99 % — 4 минуты, 99 % — больше 7 часов.
• Uptime — метрика (SLI), SLO — внутренняя цель с бюджетом ошибок, SLA — обещание в договоре с методикой и санкциями. Свой uptime считайте сами.
• Простой — это не только «не отвечает»: истёкший сертификат, 5xx и «200 без нужного контента» тоже простой. Медленный ответ и частичная недоступность — отдельные метрики.
• Честное измерение: несколько точек в разных сетях, интервал 1 минута, подтверждение с двух точек, счёт по времени инцидентов с поправкой на задержку подтверждения.
• Плановые работы отдавайте как 503 с Retry-After и показывайте отдельно от аварий.