Привет, Хабр! Меня зовут Михаил Шпаков, я руковожу разработкой в 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 отслеживаемым сертификатам расклад такой:

71,5% — Let’s Encrypt. Платные центры сертификации в этом сегменте практически исчезли, HTTPS стал бесплатной нормой, и это прекрасно. Смущает только, что почти три четверти сайтов теперь зависят от одного бесплатного CA. Интересно, что будет, если у него случится по-настоящему плохой день.
Кстати, страшилка про «протухший сертификат» почти умерла: реально просроченных сертификатов на живых сайтах единицы, автопродление победило. Но не до конца: 1 694 инцидента за год случились из-за проблем с цепочкой, когда сам сертификат в порядке, а промежуточный в цепочке нет.
❯ Бонус: как выглядит задержка из разных точек мира
Statuser проверяет сайты из пяти локаций, и по средней задержке ответа получилась любопытная география:

Из Питера и Москвы получается около полусекунды, из Амстердама 621 мс, а из Нью-Йорка 1 074 мс. Дело тут, конечно, не в Нью-Йорке: большинство сайтов из выборки размещены в России, и задержка просто растёт с расстоянием до сервера. Но в этом и практический вывод: если сайт хостится в России, а аудитория есть за её пределами, для этой аудитории он вдвое медленнее. И увидеть это можно, только проверяя сайт не из Москвы.
❯ Что из этого стоит унести с собой
Мониторьте деградацию, а не только доступность. Половина падений начинается с таймаута, то есть с медленных ответов, которые часто видно заранее по росту латентности.
Полночь — худшее время для крона и деплоя без присмотра. Если ночной инцидент не починит автоматика, лежать он будет до утра.
Проверяйте цепочку сертификатов, а не только срок действия. Проблемы с цепочкой случаются чаще, чем просроченные сертификаты.
99,99% — не данность. Три четверти сайтов её не держат. Чтобы понять, в какой группе ваш, нужно сначала начать измерять.
❯ В заключении
Если сжать год наблюдений в одну мысль, получится так: сайты падают не от катастроф, а от рутины. Таймауты, ночные кроны, забытые сертификаты, деплой в четверг после обеда. Хорошая новость в том, что с рутиной, в отличие от катастроф, можно работать: измерять, замечать закономерности и чинить причины, а не последствия.
Спасибо, что дочитали до конца! Буду рад обратной связи: вопросам, идеям или просто впечатлениям в комментариях. А если хотите узнать, сколько девяток держит ваш сайт — попробуйте Statuser.
Может быть интересно:

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩
arantar
Только ваш новый сервис Мониторинга (HTTP/HTTPS в Timeweb) у нас ложно срабатывал в более 50% случаев.
Приходит уведомление в телеге о недоступности, но по факту всё работает.
mikhailshpakov Автор
Спасибо за обратную связь
Без конкретных примеров сложно понять, что именно происходило и почему возникали такие уведомления, поскольку подобные ситуации могут возникать по разным причинам
Если сохранились детали (аккаунт в Таймвеб Клауд, что мониторилось, когда приходили уведомления, примеры инцидентов), можете написать мне в Телеграм @mshpakov, сможем разобраться в вашем конкретном кейсе