Привет, Хабр! Меня зовут Михаил Шпаков, я руковожу разработкой в Timeweb Cloud и развиваю Statuser — сервис мониторинга доступности сайтов, который когда-то начинался как вечерний пет-проект. Я уже рассказывал, как он появился, как в нём выросли статус-пейджи и зачем я научил его следить за DNS.

Той самой первой статье недавно исполнился год. Мне захотелось отметить эту дату не праздничным постом, а в духе самого Statuser: цифрами. Повод удачно совпал с устройством сервиса. Историю инцидентов он хранит ровно год, так что в базе меня ждал аккуратный годовой датасет: 108 312 инцидентов с июля 2025-го по июль 2026-го. По сути, готовая статистика о том, как живёт и падает обычный сайт.

Я залез в эти данные и хочу поделиться тем, что нашёл. Почему сайты падают на самом деле, в какое время это происходит, сколько длится типичное падение и что за странная аномалия случилась этим июнем.

Сразу честная оговорка: это не «исследование всего интернета». Это 6 500 сайтов пользователей Statuser, в основном малый и средний бизнес, интернет-магазины, SaaS, корпоративные сайты. Но на ста тысячах инцидентов закономерности видны отчётливо.

Коротко в цифрах:

  • 108 312 инцидентов за год, примерно 297 в день;

  • 5,7 минуты — медианная длительность падения;

  • 99,92% — медианный аптайм сайта;

  • 49,8% всех падений — таймаут.

❯ Почему сайты падают на самом деле

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

Половина всех инцидентов за год (53 920) — это таймаут. Сервер жив, порт открыт, но ответа в разумное время нет. Сайт не «упал», он «задумался»: перегруженная база, забитый пул воркеров, медленный внешний API. Для посетителя разницы никакой.

Причины инцидентов
Причины инцидентов

Дальше идут «сервер недоступен» (11,2%), честные 500-ки (7,4%) и bad gateway (6,9%). Последний случай особенно узнаваемый: бэкенд уже умер, а nginx остался и рапортует об этом всем желающим.

Отдельно отмечу две категории. SSL-проблемы дают около 4% инцидентов, и это самая обидная категория: почти все они предотвращаются автопродлением и проверкой цепочки. DNS даёт ещё почти 2% — та самая история, из-за которой я когда-то добавил DNS-мониторинг.

А ещё 1 867 раз за год сайты отвечали мониторингу 404-й прямо со своей главной страницы. Кто-то удалил или переместил её и просто не заметил.

❯ Когда падают: полуденный пик и полуночные деплои

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

Инциденты по часам суток (МСК)
Инциденты по часам суток (МСК)

Главный пик приходится на время с полудня до пяти вечера, худший час — 12:00 (5 160 инцидентов за год), самый спокойный — пять утра. Но посмотрите на полночь: это пятый по аварийности час суток. В 00:00 стартуют кроны, ночные деплои и всякие «давай выкатим, всё равно никто не смотрит».

Есть на графике и второй ночной бугорок, поменьше, в три часа по Москве. Я не сразу сообразил, откуда он: три ночи по Москве — это полночь по UTC. Серверы, живущие по всемирному времени, запускают свои кроны на три часа позже московских и точно так же от них падают.

Инциденты по дням недели
Инциденты по дням недели

По дням недели картина ещё красноречивее: в четверг сайты падают на треть чаще, чем в воскресенье. Сайты ломают люди, а не энтропия. В выходные никто не деплоит, и ничего не падает.

❯ Сколько длится типичное падение

47% всех падений закрываются за пять минут, ещё треть укладывается в полчаса. Типичный инцидент — это рестарт, докатившийся деплой или короткий всплеск нагрузки.

Тут важно оговориться. У большинства мониторов интервал проверки пять минут (это дефолт), поэтому и мир мониторинг видит с шагом в пять минут: «инцидент длился пять минут» на деле означает «к следующей проверке всё уже работало». Реальный простой мог быть и минуту, и тридцать секунд. Так что цифры в графике скорее оценка сверху, коротких падений на самом деле ещё больше.

Длительность инцидентов
Длительность инцидентов

Теперь хвост распределения. 3 203 инцидента длились больше суток. Это сайты, за которыми никто не следит: они падают тихо и лежат, пока кто-нибудь случайно не заметит. Собственно, ради борьбы с этим сценарием я и делаю мониторинг.

И ещё одно наблюдение, которое мне очень нравится. Медианная длительность инцидента днём и ночью почти одинаковая, около пяти с половиной минут: короткие падения чинит автоматика, а ей всё равно, который час. Зато p90 отличается заметно: 119 минут днём против 161 ночью. Длинные инциденты ночью чинят на 35% дольше. Если автоматика не справилась, дальше всё зависит от человека, а человек спит.

❯ Что случилось в июне

В июне Statuser работал как никогда много: 22 556 инцидентов за месяц, вдвое больше обычного. Уведомления улетали пользователям почти каждую минуту. И это не эффект роста базы мониторов: в пересчёте на один сайт вышло 3,54 инцидента при годовой норме 1,5–2.

Инцидентов на один монитор по месяцам
Инцидентов на один монитор по месяцам

Если развернуть июнь по дням, видно, что это был не один большой сбой, а три отчётливые волны: 9–11, 17–18 и 23–25 июня. Худший день года — 24 июня: 1 169 инцидентов на 326 разных сайтах за сутки.

Инциденты по дням
Инциденты по дням

Самое интересное в этих волнах — профиль. Обычно на сетевые причины (таймауты и недоступность хоста) приходится 60–63% инцидентов, а в июньские волны доля доходила до 78%. То есть сами приложения продолжали работать, но переставали быть доступными по сети. О причинах рассуждать не возьмусь: думаю, многие и сами помнят, каким выдался июнь. Покажу только то, что видно в данных.

Доля сетевых причин в инцидентах по неделям
Доля сетевых причин в инцидентах по неделям

К июлю всё стабилизировалось, но только наполовину. По числу инцидентов в день волны прошли: после 26 июня ни один день не поднимался выше 750 против 1 169 в пике. А вот структура ошибок к норме не вернулась: доля сетевых причин и в последнюю неделю июня (71%), и в июле (70%) держится заметно выше майских 60–63%. Да и в абсолютных числах июль пока в полтора раза аварийнее мая.

❯ Кто держит девятки

«У нас аптайм 99,9%» — любимая фраза маркетинговых материалов. Я решил проверить, как обстоят дела на практике, и посчитал средний аптайм за последние 90 дней по всем активным мониторам.

Распределение сайтов по аптайму
Распределение сайтов по аптайму

Медианный сайт держит 99,92%, то есть около 35 минут простоя в месяц. Неплохо! Но до «четырёх девяток» дотягивает только каждый четвёртый сайт, а 15% живут с аптаймом ниже 95% — это больше полутора суток простоя ежемесячно. И, судя по хвосту из прошлого раздела, владельцы чаще всего об этом просто не знают.

❯ SSL: монокультура одного центра сертификации

Из побочных находок. Statuser проверяет SSL-сертификаты, и по 4 643 отслеживаемым сертификатам расклад такой:

Кто выдаёт SSL-сертификаты
Кто выдаёт SSL-сертификаты

71,5% — Let’s Encrypt. Платные центры сертификации в этом сегменте практически исчезли, HTTPS стал бесплатной нормой, и это прекрасно. Смущает только, что почти три четверти сайтов теперь зависят от одного бесплатного CA. Интересно, что будет, если у него случится по-настоящему плохой день.

Кстати, страшилка про «протухший сертификат» почти умерла: реально просроченных сертификатов на живых сайтах единицы, автопродление победило. Но не до конца: 1 694 инцидента за год случились из-за проблем с цепочкой, когда сам сертификат в порядке, а промежуточный в цепочке нет.

❯ Бонус: как выглядит задержка из разных точек мира

Statuser проверяет сайты из пяти локаций, и по средней задержке ответа получилась любопытная география:

Средняя задержка ответа по точкам проверки
Средняя задержка ответа по точкам проверки

Из Питера и Москвы получается около полусекунды, из Амстердама 621 мс, а из Нью-Йорка 1 074 мс. Дело тут, конечно, не в Нью-Йорке: большинство сайтов из выборки размещены в России, и задержка просто растёт с расстоянием до сервера. Но в этом и практический вывод: если сайт хостится в России, а аудитория есть за её пределами, для этой аудитории он вдвое медленнее. И увидеть это можно, только проверяя сайт не из Москвы.

❯ Что из этого стоит унести с собой

  • Мониторьте деградацию, а не только доступность. Половина падений начинается с таймаута, то есть с медленных ответов, которые часто видно заранее по росту латентности.

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

  • Проверяйте цепочку сертификатов, а не только срок действия. Проблемы с цепочкой случаются чаще, чем просроченные сертификаты.

  • 99,99% — не данность. Три четверти сайтов её не держат. Чтобы понять, в какой группе ваш, нужно сначала начать измерять.

❯ В заключении

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

Спасибо, что дочитали до конца! Буду рад обратной связи: вопросам, идеям или просто впечатлениям в комментариях. А если хотите узнать, сколько девяток держит ваш сайт — попробуйте Statuser.

Может быть интересно:
Перейти ↩

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале 

Комментарии (2)


  1. arantar
    14.07.2026 08:22

    Только ваш новый сервис Мониторинга (HTTP/HTTPS в Timeweb) у нас ложно срабатывал в более 50% случаев.
    Приходит уведомление в телеге о недоступности, но по факту всё работает.


    1. mikhailshpakov Автор
      14.07.2026 08:22

      Спасибо за обратную связь

      Без конкретных примеров сложно понять, что именно происходило и почему возникали такие уведомления, поскольку подобные ситуации могут возникать по разным причинам

      Если сохранились детали (аккаунт в Таймвеб Клауд, что мониторилось, когда приходили уведомления, примеры инцидентов), можете написать мне в Телеграм @mshpakov, сможем разобраться в вашем конкретном кейсе