При выборе хостинга для коммерческого проекта большинство разработчиков руководствуются простыми критериями: стабильность, отзывы, многолетняя репутация компании и гарантированный SLA. Когда ваш сервис начинает расти, вы осознанно готовы переплачивать за инфраструктуру, рассчитывая, что взамен получите аптайм, близкий к идеальному, Tier III дата-центры и адекватную реакцию на инциденты. Именно из этой логики я исходил, арендуя VPS в локации Нидерланды (Амстердам) у компании Timeweb Cloud. Цены здесь в среднем выше, чем у ряда зарубежных аналогов или лоукост-провайдеров. Но репутация надежного российского игрока с зарубежными нодами подкупала.

Какое-то время всё действительно работало в штатном режиме. Но начиная с мая 2026 года инфраструктура Амстердама превратилась в вечную проблему для пользователей и клиентов.

В этой статье я подробно, с таймлайном, цифрами и фактами, покажу, как хостинг методично уничтожает доступность клиентских сервисов, скрывает реальные масштабы аварий на статус-страницах и оставляет пользователей один на один с лежащими серверами.

Обещания vs реальность. Что заявляет Timeweb

Перед тем как перейти к хронике падений, давайте вспомним, за что именно клиенты платят деньги Timeweb Cloud:

Обещания:

• Гарантированный SLA 99,98% доступности сети и инфраструктуры

• Уровень дата-центров - соответствие стандартам Tier III.

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

Если перевести SLA 99,98% на понятный язык, то допустимый простой (downtime) составляет в месяц не более 8 минут 45 секунд или в год не более 1 часа 45 минут.

А теперь посмотрим, что произошло на самом деле всего за полтора месяца в Таймвебе.

Таймлайн сбоев (май – июнь 2026)

Отключение электричества и недоступность сети в локации AMS (Амстердам, Нидерланды)

Ниже приведен список только крупных, зафиксированных инцидентов полной недоступности серверов. Мелкие отвалы на 5–10 минут сюда даже не включены.

• 23 мая: Полная недоступность серверов более 3 часов.

• 25 мая: Повторный инцидент. Сервисы лежат более 5 часов.

• 26 мая: Очередной сбой, сеть и дисковая подсистема недоступны более 5 часов.

• 27 мая: Четвертый день подряд! Инфраструктура Амстердама парализована более чем на 5 часов.

Итог за 4 дня мая: Около 18 часов простоя. Это превышает годовую норму SLA в 10 раз. Поддержка отвечает стандартными отписками про проблемы на стороне вышестоящего провайдера и наши инженеры уже работают.

После майского коллапса ситуация не стабилизировалась. Наступил июнь:

• 5 июня: Инцидент с сетевой связностью, простой менее 1 часа.

• 28 июня: Очередной дневной сбой, простой более 3 часов.

• 29–30 июня: Апофеоз. Начиная с 22:00 серверы полностью легли и остаются недоступны более 15 часов подряд (на момент написания статьи).

Итоговый downtime за 1.5 месяца перевалил за 35 часов. Проекты теряют клиентов, владельцы бизнесов теряют репутацию, рекламные бюджеты сливаются в никуда.

Бесконечные DDoS-атаки и шторм в RU-локациях (МСК/СПБ)

Проблемы Timeweb Cloud давно вышли за пределы одной лишь европейской ноды. Пока Амстердам страдает от физических проблем и сетевой связности, остальные клиенты, выбравшие серверы в Москве и Санкт-Петербурге, регулярно наблюдают за тем, как их проекты «прикладывают» из-за непрекращающихся DDoS-атак на инфраструктуру хостинга.

Из-за того, что под ударом периодически оказываются магистральные каналы и сетевой периметр провайдера, рикошетом задевает абсолютно сторонние серверы, которые никак не связаны с атакуемыми ресурсами. Клиенты в РФ получают точно такой же букет проблем: просадки по пингам, кратковременные отвалы баз данных и недоступность панелей управления. В итоге безопасной гавани в инфраструктуре TW сейчас просто нет.

Всё зелёное. Как Timeweb рисует статус-страницу

Один из самых раздражающих факторов во всей этой истории — поведение статус-страницы (Status Page) на официальном сайте хостинга.

Когда твой мониторинг бьет тревогу, клиенты пишут в личку, а API возвращает 502 или Connection Timeout, ты заходишь на страницу статуса Timeweb и видишь прекрасную картину:

Локация «Амстердам» (AMS-1) и другие локации либо горят гордым зеленым цветом («все системы работают штатно»), либо в лучшем случае подсвечивается желтым («Незначительные ухудшения производительности»).

Для кого пишется этот статус? Очевидно, для потенциальных клиентов, чтобы не портить общую статистику аптайма на главной странице. Действующие клиенты в этот момент штурмуют техническую поддержку, пробиваясь сквозь стандартные отписки и скрипты первой линии.

Канал алертов и реакция сообщества

В официальном канале алертов и в комментариях под постами хостинга разворачивается настоящая драма. Пользователи массово выражают недоумение, переходящее в ярость.

Важное примечание: Всё, что вы видите на скриншотах выше — это лишь верхушка айсберга, которую я успел перехватить в реальном времени. В Timeweb Cloud развернута жесточайшая модерация. Практически любая конструктивная критика, неудобные вопросы про компенсации или детальные хроники падений методично удаляются из чата сообщества со временем, как только спадает первая волна паники.

Более того, администрация нашла «гениальный» способ борьбы с паникой во время крупных инцидентов:

• Отключение чата. На время ночных или затяжных сбоев возможность отправки сообщений для комьюнити просто блокируется (чат переводят в режим «только чтение»).

• Slow Mode. Периодически включается Slow Mode с ограничением на отправку — одно сообщение в час. Делается это с одной целью: искусственно замолчать масштаб катастрофы, связать пользователям руки и дать модераторам время зачищать неугодный контент.

Если зайти во вкладку «Идеи» на сайте Timeweb, то самые популярные и залайканные предложения пользователей сейчас выглядят следующим образом:
1. «Почините наконец Амстердам».
2. «Сделайте автоматический бэкап в другую локацию при падении ноды».
3. «Перестаньте врать в статус-панели».

Клиенты пишут: «Мы выбрали вас из-за стабильности, платим x2 от рынка, а в итоге получаем доступность на уровне бесплатного тестового хостинга из 2010 года».

Финансовые и репутационные последствия для разработчиков и бизнеса

Когда падает крупный сервис, у него есть дежурная смена sysops, резервные контуры в других облаках и юридический отдел. Когда падает проект независимого разработчика или небольшого стартапа, последствия куда болезненнее.

Во-первых, это отток пользователей. Люди не будут разбираться, виноват ли Timeweb или магистральный провайдер в Амстердаме. Они видят, что сервис не работает, и уходят к конкурентам.

Во-вторых, отсутствие реальной компенсации. Регламент компенсаций по SLA у Timeweb зачастую сформулирован так, что вам вернут копейки от стоимости самой VPS за время простоя. Но никто не компенсирует потерянную прибыль, упущенных клиентов и затраты на рекламу.

Время собирать вещи?

Данный материал — не просто жалоба, а фиксация системного кризиса инфраструктуры конкретного провайдера. Если проблемы длятся несколько дней, можно сослаться на форс-мажорную ситуацию. Если проблемы повторяются системно на протяжении двух месяцев, а статус-индикаторы продолжают гореть зеленым — это уже целенаправленное введение пользователей в заблуждение и неспособность менеджмента решить технические проблемы.

Вопросы к сообществу Хабра:
1. Кто еще столкнулся с регулярными падениями Амстердама в Timeweb за май-июнь?
2. Как реагирует поддержка и удается ли выбить реальную компенсацию за бизнес-потери?
3. Куда сейчас наиболее безболезненно мигрировать инфраструктуру с сохранением адекватной связности и стабильности?

Приглашаю всех пострадавших коллег высказаться в комментариях. Давайте соберем честную статистику аптайма, которую хостинг так тщательно скрывает.