TL;DR. Я выбирал Timeweb не из-за цены, а из-за «имени» и обещанной надёжности. За май–июнь 2026 года зона ams-1 (Амстердам, дата-центр Qupra) пережила шесть крупных аварий с суммарным окном недоступности около 46 часов — причём последняя авария на момент написания этих строк всё ещё не закрыта и идёт уже более 15 часов. Хостер на своём сайте обещает Tier III и аптайм 99,98 % — это 1 час 45 минут простоя в год. За два месяца факт превысил годовой лимит этого обещания примерно в 26 раз. Все цифры ниже — не мои домыслы и не «жалобы в чате», а сообщения из официального канала статусов самого Timeweb.

Почему я вообще выбрал Timeweb

Сразу зафиксирую, чтобы не было подмены понятий: я не из тех, кто ищет «лишь бы подешевле».

Я прекрасно понимаю, что для критически важных проектов нужно строить отказоустойчивую архитектуру — репликации, балансировщики, несколько площадок. Это нормальная инженерная практика, и я не спорю с ней.

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

И вот с этим обещанием возникли проблемы.

Что обещает сам хостер

На сайте Timeweb прямо написано: инфраструктура размещается в дата-центрах уровня Tier III с коэффициентом отказоустойчивости не менее 99,98 %.

Давайте посчитаем, что это значит на практике. В году 8 766 часов. 99,98 % аптайма — это значит, что на простой отводится:

0,02 % × 8 766 ч ≈ 1,75 часа = 1 час 45 минут в ГОД.

Запомним эту цифру: 1 час 45 минут в год. Это тот бюджет недоступности, который хостер сам себе назначил своим маркетингом.

А теперь — что было на самом деле.

Что происходило в Амстердаме на самом деле

Я собрал хронологию по официальному каналу статусов Timeweb (@timewebcloud_alerts) — это их собственный рупор, куда они сами публикуют аварии. Вот что было в зоне ams-1 (дата-центр Qupra, Нидерланды) всего за два месяца:

Итого: около 46 часов недоступности за 61 день — и счётчик ещё крутится.

И отдельно подчеркну про последнюю строку. Авария началась 29 июня в 21:44 мск. Я пишу эти строки спустя более чем 15 часов — и в канале статусов всё ещё висит «продолжаем заниматься системой кондиционирования, ожидаем информации по срокам окончательного запуска». Один этот инцидент уже в ~8–9 раз перекрыл весь годовой бюджет простоя по их SLA. И он ещё не закончился.

Каждый столбец — отдельная авария. Синяя пунктирная линия у самого нуля — это весь годовой бюджет простоя, который хостер сам себе разрешил своим SLA 99,98 %.

Сравним с обещанием:

• Обещанный бюджет простоя: 1 ч 45 мин в год.

• Факт ams-1: ~46 часов за два месяца (и это без учёта того, что последняя авария ещё идёт).

• Это примерно 26-кратное превышение годового лимита SLA — и не за год, а за два месяца.

• Фактическая доступность ams-1 за май–июнь получается ~96,8 % против заявленных ≥ 99,98 %.

Честная оговорка, чтобы меня не поймали на передёргивании. В таблице — окно «от первого сообщения об аварии до сообщения „инцидент закрыт“», то есть время до полного восстановления. В части инцидентов хостер указывал частичный аффект («7 % нод», «34 ноды»). Но 23 и 27 мая — это, по их же словам, полное обесточивание машинного зала. Даже если делать поправку на частичность, порядок величины не меняется: это не «1 час 45 минут в год».

Это не невезение. Это системная проблема

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

Хронология говорит сама за себя:

• 23 мая — авария питания из-за жары.

• 25 мая Timeweb пишет, что ДЦ «апгрейдит систему охлаждения машинных залов» — как реакцию на 23 мая.

• 26 мая — авария повторяется.

• 27 мая — система охлаждения полностью выключается, все стойки обесточивают.

• А потом, в июне, всё повторяется снова — 26-го и дважды 29-го.

То есть «ремонт» причину не устранил. Авария воспроизводится через дни и недели. Это и есть определение системной проблемы, а не форс-мажора.

И отдельно — прямое признание самого хостера. 27 мая в их канале:

«За простой в зоне ams-1 за 23, 26 и 27 мая будет сделан перерасчёт после полного восстановления площадки.»

Три аварии за пять дней — официально, их же словами.

Обещанный постмортем, которого нет

Отдельная деталь, которая многое говорит об отношении к клиентам.

По майскому кластеру аварий хостер дважды публично пообещал постмортем:

• 23 мая (закрытие инцидента): «Подробный постмортем с разбором причин опубликуем отдельно».

• 27 мая: «По итогам отчёта площадки выпустим постмортем».

Прошёл месяц с лишним. Этого постмортема нет — ни в канале статусов, ни в их блоге на Хабре. И это особенно красноречиво на контрасте: разборы по другим, куда менее масштабным инцидентам они спокойно публиковали — постмортем по libvirt, по сбою S3, по дисковой подсистеме в зоне MSK-1. То есть механика «признать и разобрать» у компании есть. Но по самой крупной и позорной серии аварий — отказам питания и охлаждения в Амстердаме — наступила тишина.

Заметить разницу несложно: по мелким инцидентам отчитываемся, по крупным — молчим и надеемся, что забудут.

«За такие деньги чего вы хотите» и «поднимите реплики»

В любом подобном обсуждении обязательно появляются два аргумента, и оба я считаю несостоятельными.

Первый: «за такие деньги чего вы хотите». Я уже сказал: Timeweb не дешёвый. За те же деньги OVH даёт более мощное железо. Я платил премию за надёжность — и именно её не получил.

Второй: «поднимите реплики, поставьте балансировщик, стройте отказоустойчивую архитектуру». Да, для высоконагруженных проектов это нормальная практика. Но давайте не подменять понятия.

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

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

Никого из нас не интересует, чей именно кондиционер сломался, кто виноват и что произошло на площадке подрядчика. Мы покупаем услугу у Timeweb, а не у Qupra. Если выбранный дата-центр не способен обеспечить стабильную работу — значит, его нужно менять. Это зона ответственности хостера, а не клиента.

Будем честны: не всё — вина хостера

Чтобы статья была честной, а не охотой на ведьм, отделю мух от котлет.

Если посмотреть на канал алертов целиком, видно ещё один большой пласт инцидентов — DDoS-атаки на локацию Нидерланды (особенно зимой 2024–2025, когда волны шли почти ежедневно, и периодически в 2026-м). Вот это я в вину Timeweb не ставлю. DDoS — внешний фактор, отражение атак — это нормальная боль любого провайдера, и они с ней работали.

Моя претензия — конкретная и узкая: кластер отказов питания и охлаждения в ДЦ Qupra в мае–июне 2026 года. Это не хакеры. Это инженерная инфраструктура площадки, за которую отвечает хостер. И именно она сыпалась раз за разом.

Серое — DDoS (внешний фактор, к хостеру претензий нет). Красное — инфраструктура и сеть. Хорошо виден зимний пик DDoS 2024–25 и отдельный майско-июньский кластер инфраструктурных отказов 2026 года.

Почему я ухожу

Я принял решение переезжать. И не из-за одной аварии — аварии случаются у всех. А из-за того, что это стало системной историей: один и тот же дата-центр за два месяца регулярно становится причиной масштабных простоев, причём по одной и той же причине.

После такого надеяться на очередное «теперь всё будет стабильно» я больше не вижу смысла. Доверие к инфраструктуре в этой локации у меня потеряно.

И мне правда жаль. В остальном сервис Timeweb действительно удобный — приятная панель, нормальная поддержка. Но никакая панель управления не компенсирует постоянные простои. Когда твой проект в Амстердаме лежит десятки часов за два месяца, удобство интерфейса перестаёт что-либо значить.

Фактбокс

• Источник всех данных — официальный канал статусов Timeweb @timewebcloud_alerts.

• 6 крупных аварий (Major) в зоне ams-1 за 61 день (май–июнь 2026).

• ~46 часов суммарного окна недоступности (последняя авария ещё идёт).

• Обещанный SLA 99,98 % = 1 ч 45 мин/год → факт ≈ в 26 раз больше за 2 месяца.

• Фактическая доступность ams-1 ≈ 96,8 % против обещанных ≥ 99,98 %.

• 3 аварии за 5 дней (23/26/27 мая) — по признанию самого хостера.

• Повторяющаяся первопричина: охлаждение / электропитание ДЦ Qupra.

• Обещанный постмортем по майскому кластеру так и не опубликован.

Какие выводы я сделал для себя

1. Маркетинговый SLA ≠ договорной SLA. «99,98 %» на лендинге — это обещание, а не обязательство с компенсацией. Читайте договор: что именно гарантируется и что вы реально получите за простой.

2. Смотрите не на витрину, а на канал статусов. У многих провайдеров есть публичный канал инцидентов. Полистайте его за год до того, как занести деньги, — там вся правда о площадке.

3. Конкретная локация важнее бренда. Проблема была не у «Timeweb вообще», а у конкретного ДЦ Qupra в Амстердаме. Выбирайте зону, а не только провайдера.

4. Отказоустойчивость — ваша страховка от редких сбоев, а не замена базовому аптайму провайдера. Если реплики нужны, чтобы пережить отказ кондиционера в ДЦ, — это проблема провайдера, а не ваша.

А если у вас инфраструктура в этой же зоне — поделитесь в комментариях, совпадает ли ваша картина простоев с этой хронологией. Будет интересно собрать статистику с разных аккаунтов.

Слово хостеру: право на ответ

Я сознательно не делаю из этого «приговор без защиты». У Timeweb есть аккаунт здесь, на Хабре — @Timeweb_Cloud, — и я буду рад, если коллеги придут в комментарии и ответят по существу. Вопросы у меня предметные:

1. Где обещанный постмортем по майскому кластеру ams-1? Вы дважды публично обещали его (23 и 27 мая). Прошёл месяц — разбора нет. По libvirt, S3 и дискам в MSK-1 постмортемы вы выпускали. Почему по самой крупной серии аварий — тишина?

2. Что конкретно сделано с охлаждением в ДЦ Qupra? После 23 мая вы писали об «апгрейде системы охлаждения». Но 26, 27 мая и весь июнь авария повторялась. Что именно заменили/починили и почему это не сработало?

3. Будет ли перерасчёт? 27 мая вы обещали перерасчёт за 23, 26 и 27 мая. Он сделан? А за июньские простои? По какой методике считается компенсация?

4. Рассматриваете ли вы смену площадки в Нидерландах? Если конкретный дата-центр системно не держит охлаждение — это вопрос смены подрядчика, а не «ещё одного обновления прошивки».

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