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 мая — это, по их же словам, полное обесточивание машинного зала.
Это системная проблема
Если бы это были шесть разных, не связанных между собой сбоев — можно было бы говорить о неудачном стечении обстоятельств. Но посмотрите на причины: раз за разом одно и то же — охлаждение и электропитание дата-центра Qupra.
Хронология говорит сама за себя:
23 мая — авария питания из-за жары.
25 мая Timeweb пишет, что ДЦ «апгрейдит систему охлаждения машинных залов» — как реакцию на 23 мая.
26 мая — авария повторяется.
27 мая — система охлаждения полностью выключается, все стойки обесточивают.
А потом, в июне, всё повторяется снова — 26-го и дважды 29-го.
То есть «ремонт» причину не устранил.
И отдельно — прямое признание самого хостера. 27 мая в их канале:
«За простой в зоне ams-1 за 23, 26 и 27 мая будет сделан перерасчёт после полного восстановления площадки.»
Три аварии за пять дней — официально, их же словами.
Обещанный постмортем, которого нет
Отдельная деталь, которая многое говорит об отношении к клиентам.
По майскому кластеру аварий хостер дважды публично пообещал постмортем:
23 мая (закрытие инцидента): «Подробный постмортем с разбором причин опубликуем отдельно».
27 мая: «По итогам отчёта площадки выпустим постмортем».
Прошёл месяц с лишним. Этого постмортема нет — ни в канале статусов, ни в их блоге на Хабре. При этом есть разборы по другим, куда менее масштабным инцидентам они спокойно публиковали — постмортем по libvirt, по сбою S3, по дисковой подсистеме в зоне MSK-1. То есть механика «признать и разобрать» у компании есть. Но по самой крупной и позорной серии аварий — отказам питания и охлаждения в Амстердаме — наступила тишина.
Заметить разницу несложно: по мелким инцидентам отчитываемся, по крупным — молчим и надеемся, что забудут.
«За такие деньги чего вы хотите» и «поднимите реплики»
В любом подобном обсуждении обязательно появляются два аргумента, и оба я считаю несостоятельными.
Первый: «за такие деньги чего вы хотите». Я уже сказал: Timeweb не дешёвый. За те же деньги OVH даёт более мощное железо. Я предпочел заплатить за надёжность — и именно её не получил. На минуточку, цены у Timeweb среди РУ-хостеров раза в 3 выше.
Второй: «поднимите реплики, поставьте балансировщик, стройте отказоустойчивую архитектуру». Да, для высоконагруженных проектов это нормальная практика. Но давайте не подменять понятия.
Отказоустойчивость на стороне клиента — это инструмент защиты бизнеса от редких инцидентов. Это не способ компенсировать то, что инфраструктура провайдера регулярно становится источником масштабных простоев. Это разные уровни ответственности.
Базовый аптайм обязан обеспечивать сам хостинг. Если клиент вынужден строить сложную мульти-региональную схему только для того, чтобы пережить отказы кондиционера в ДЦ провайдера, — значит, провайдер перекладывает свою работу на клиента. И при этом берет за это деньги.
Никого из нас не интересует, чей именно кондиционер сломался, кто виноват и что произошло на площадке подрядчика. Мы покупаем услугу у Timeweb, а не у Qupra. Если выбранный дата-центр не способен обеспечить стабильную работу — значит, его нужно менять. Это зона ответственности хостера, а не клиента.
Будем честны: не всё — вина хостера
Если посмотреть на канал алертов целиком, видно ещё один большой пласт инцидентов — DDoS-атаки на локацию Нидерланды (особенно зимой 2024–2025, когда волны шли почти ежедневно, и периодически в 2026-м). Вот это я в вину Timeweb не ставлю. DDoS — внешний фактор, отражение атак — это нормальная боль любого провайдера, и они с ней работали.
Моя претензия — конкретная и узкая: кластер отказов питания и охлаждения в ДЦ Qupra в мае–июне 2026 года. Это не хакеры. Это инженерная инфраструктура площадки, за которую отвечает хостер. И именно она постоянно подводит.
Серое — DDoS (внешний фактор, к хостеру претензий нет). Красное — инфраструктура и сеть. Хорошо виден зимний пик DDoS 2024–25 и отдельный майско-июньский кластер инфраструктурных отказов 2026 года.
Почему я ухожу
Я принял решение переезжать. И не из-за одной аварии — аварии случаются у всех. А из-за того, что это стало системной историей: один и тот же дата-центр за два месяца регулярно становится причиной масштабных простоев, причём по одной и той же причине.
После такого надеяться на очередное «теперь всё будет стабильно» я больше не вижу смысла. Доверие к инфраструктуре в этой локации у меня потеряно.
И мне правда жаль. В остальном сервис Timeweb действительно удобный — приятная панель, нормальная поддержка. Но никакая панель управления не компенсирует постоянные простои. Когда твой проект в Амстердаме лежит десятки часов за два месяца, удобство интерфейса перестаёт что-либо значить.
А если у вас инфраструктура в этой же зоне — поделитесь в комментариях, совпадает ли ваша картина простоев с этой хронологией. Будет интересно собрать статистику от других пользователей.
Слово хостеру: право на ответ
Я сознательно не делаю из этого «приговор без защиты». У Timeweb есть аккаунт здесь, на Хабре — @Timeweb_Cloud, — и я буду рад, если коллеги придут в комментарии и ответят по существу. Вопросы у меня предметные:
Где обещанный постмортем по майскому кластеру ams-1? Вы дважды публично обещали его (23 и 27 мая). Прошёл месяц — разбора нет. По libvirt, S3 и дискам в MSK-1 постмортемы вы выпускали. Почему по самой крупной серии аварий — тишина?
Что конкретно сделано с охлаждением в ДЦ Qupra? После 23 мая вы писали об «апгрейде системы охлаждения». Но 26, 27 мая и весь июнь авария повторялась. Что именно заменили/починили и почему это не сработало?
Будет ли перерасчёт? 27 мая вы обещали перерасчёт за 23, 26 и 27 мая. Он сделан? А за июньские простои? По какой методике считается компенсация?
Рассматриваете ли вы смену площадки в Нидерландах? Если конкретный дата-центр системно не держит охлаждение — это вопрос смены подрядчика.
Если по любому из пунктов я ошибся или у вас есть данные, опровергающие мои цифры, — приходите, поправьте. Все мои выкладки взяты из вашего же канала статусов, ссылки на конкретные посты приложу в комментариях. Я честно обновлю статью.
Комментарии (85)
linux-over
30.06.2026 10:1246 часов простоя в Амстердаме за два месяца
В Москве ровно то же самое:
постоянно отваливается IPv6 (не реже раза в 3-4 дня) - reboot узла помогает, но почему-то reboot всегда занимает 3 минуты ровно (хотя что там VDS'у перегружаться то так долго?)
-
на регулярно пропадающую связь практически бесполезно жаловаться, вот цитата из того, что они отвечают:
В общем, чувствую, сделал глупость оплатив хостинг на год вперёд - придётся подыскивать другое место.
andreymal
30.06.2026 10:12почему-то reboot всегда занимает 3 минуты ровно (хотя что там VDS'у перегружаться то так долго?)
Как минимум логи-то почитайте, это вполне может виснуть какой-нибудь ваш собственный процесс
linux-over
30.06.2026 10:12у меня там один nginx и ничего в нём нет. а такой долгий reboot был там с самого начала
PS: там кстати сам reboot быстрый, но вот доступность машины после reboot восстанавливается каким-то cron-скриптом (кмк).
то есть я делаю reboot, затем сервер сразу отовсюду пингуется, но ни один из портов не открыт.
затем ровно через три минуты доступность есть и если зайти по ssh то в логах написано что всё загрузилось 3 минуты назад.
Botanegg
30.06.2026 10:12systemd-analyze blame
Почти наверняка там wait-online, а вам на каком то из интерфейсов не выдается ИП адресlinux-over
30.06.2026 10:12Почти наверняка там wait-online, а вам на каком то из интерфейсов не выдается ИП адрес
да,
systemd-analyze blame|head
2min 254ms systemd-networkd-wait-online.service
34.293s apt-daily.service
32.144s dhcpcd6.service
но так было с самого старта VDS.
поскольку на узле постоянно отваливается IPv6, то думаю, что именно его адрес и выдаётся очень долго
TemArtem
30.06.2026 10:12Если проблема системная и саппорт кормит отписками, проще переехать на другой vps и не тратить время на дебаг чужой инфраструктуры
andreymal
30.06.2026 10:12Рассматриваете ли вы смену площадки в Нидерландах?
Другой хостинг пишет, что других вариантов в общем-то и нет, с РФ готовы сотрудничать не только лишь все
masasibata Автор
30.06.2026 10:12
Статусы сервисов, выделенные - живые. 
ДЦ где размещаются сервера При этом во втором ДЦ, где расположены выделенные сервера все работает исправно. Получается альтернативы есть, даже если есть проблема с размещением у РФ хостеров.
Не думаю что поставить пару стоек туда - большая проблема. Да и зарегестрировать юр. лицо в той же грузии тоже.
aLx2024
30.06.2026 10:12Похоже hostkey там же пасётся. Отвал вчера, пока не работает. Был и вчера утром.
itGuevara
30.06.2026 10:12Есть сайт, где публикуется сводная информация? Коэффициент готовности реальный и плановый для разных (всех) ЦОД?
JimRaynor
30.06.2026 10:12Может посоветуете хостера? я тоже от этих падений буггурчу постоянно
UplandDivan
30.06.2026 10:12Вы бы требования обозначили: на какую аудиторию - для себя/российскую/международную, есть ли возможность оплаты зарубежной картой или криптой, или только российской.
nfrvnikita
30.06.2026 10:12Забанили за название этой статьи, вот и думайте...
Забанили за название этой статьи :) 
alegnye
30.06.2026 10:12Меня тоже забанили за вопрос о причинах, почему почти не информируют о ходе решения проблемы, и как будто замалчивают её. А сейчас, смотрю, вообще закрыли комментарии в ТГ. Ну раз на собственном канале рты затыкают, то будем делиться отзывами на сторонних ресурсах.
gotch
30.06.2026 10:12Вроде можно понять, но сравнив температуру за два года, не настолько уж она и выше в 2026-м.
Май 2025 Meteociel - Climatologie mensuelle de Amsterdam Airport Schiphol ( Netherlands )
Май 2026 Meteociel - Climatologie mensuelle de Amsterdam Airport Schiphol ( Netherlands )
Июнь 2025 Meteociel - Climatologie mensuelle de Amsterdam Airport Schiphol ( Netherlands )
Июнь 2026 Meteociel - Climatologie mensuelle de Amsterdam Airport Schiphol ( Netherlands )
Вывод: хостер не готов к температуре 30 градусов.
Arhammon
30.06.2026 10:12Если вы в сильную жару захотите приобрести, починить итп. кондиционер то вероятно откроете для себя "Не эластичное предложение" в виде недельной очереди...
gotch
30.06.2026 10:12Для себя да, а на работе люди по договору. Сегодня позвонили, самое позднее завтра пришли. Оплачено.
Arhammon
30.06.2026 10:12Ну так при "аномальной жаре" у тебя позвонили и из датацентра и из мясокомбината и из больницы какой-нибудь, а кондиционерщика/холодильщика допустим два, и далее продолжаем спускаться по ступеням - у поставщиков запасы запчастей в расчете на определенный спрос...
Akuma
30.06.2026 10:12У других хостеров там же тоже были проблемы. Дело не столько в таймвебе, сколько в случае.
Так-то я тоже от них ушел, но просто потому что нашел то же самое дешевле. В остальном хостер как хостер.
Селектел у меня тоже регулярно проблемы вызывает, хотя считает чуть ли не эталоном.
d3d14
30.06.2026 10:12Нейрослоп.
Я платил за обещание, а не за минимальный ценник.
Это не невезение. Это системная проблема
Даже заметку про хостинг не могут написать самостоятельно.
masasibata Автор
30.06.2026 10:12А для чего? Тезисы и факты мои, ИИ только помог оформить текст. Сейчас 2026 год, нет смысла тратить время на то, что можно автоматизировать. Обсуждать стоит аргументы статьи, а не инструмент, которым она написана.
yellowmew
30.06.2026 10:12по правилам хабра использование ИИ при подготовке статей запрещено, вы же знаете? )
d3d14
30.06.2026 10:12Я читаю, как у нейросети есть претензии к хостеру.
Вот хотя бы:Я платил за обещание, а не за минимальный ценник.
Но нейросети пока еще не могут ни за что платить.
Это просто неуважение к читателям. Зачем вы пишите этот пост? Он адресован живым читателям или поисковым механизмам с целью понижения репутации хостера? Если второе - то почему живые люди вынуждены этот видеть?
Nickroc
30.06.2026 10:12Тоже хотел писать, как можно деградировать настолько, что пост вида "Упал сервак" пишет нейросеть
Acceleratore
30.06.2026 10:12Проблема в том, что "ии помог оформить текст" это по результату гребанная вода. Вашу статью можно сократить раза в 3-4, ничего не потеряет, зато читать будет легче.
Вот для чего, уважать людей, которые будут читать, а не "гы гы гы, ИИ всё напишет сама, обдумывать текст не нужно".
UplandDivan
30.06.2026 10:12Осуждаю. Всё же статья - это диалог автора с читателями, где читатель ожидает увидеть живого автора, его собственный слог и стиль, а не робота, которому дали задание сгенерировать текст по указанным тезисам.
atomlib
30.06.2026 10:12ИИ только помог оформить текст
Искусственный интеллект вам помог испортить текст. Не понимаю, откуда берётся это убеждение, будто большие языковые модели обладают хорошим стилем. Всегда одно и то же от нейросетей: штампы, повторы, общая раздутость, а если попросить лаконично — недосказанность и неупомянутые факты. Нужно наоборот, требовать от агента с БЯМ искать и анализировать информацию, а писать должны люди.
Пожалуйста, перечитайте ваш текст. Там многое несколько раз повторяется, в том числе в этом фактбоксе.
Сейчас 2026 год, нет смысла тратить время на то, что можно автоматизировать.
Если вы не удосижились потратить время на написание текста, с чего вы взяли, что мы должны тратить время на его чтение?
Сейчас 2026 год, человеческие тексты ценятся как никогда высоко.
Barnaby
30.06.2026 10:12Два дня в месяц был недоступен сервер?
У вдсина сервер был доступен два дня в этом месяце
reid2
30.06.2026 10:12Я как айтишник, да и Вы в большинстве кто на этом ресурсе- должны понимать. Да аварии бывают, да мы всегда стараемся все сделать и даже лучше чем было в условиях выделенных бюджетов. Там реально проблема- жара. Такой никогда не было. Даже если писать что сегоня не жарко и все равно серверы упали. Там охлад пережил "апокалипсис" Ему и сейчас плохо. Да починят, да нарушен uptime. Но лично у меня претензий ноль. 1. я ин понимаю, и понимаю как это все устроено. 2. я покупал сервера без дублирования. И был в курсе. Допустим там цунами, торнадо, наводнение пройдёт- также будете писать во все инстанции? PS- рядовой пользователь. Отношения ни к таймвеб ни хосткей не имею
andreymal
30.06.2026 10:12Там реально проблема- жара. Такой никогда не было.
То, что Qupra падал в январе из-за той же самой системы охлаждения, вспоминать тактично не будем)
gotch
30.06.2026 10:12Слишком жарко! Слишком холодно! )
На самом деле у нас тоже в холод с кондиционированием проблемы, падает давление хладагента и оно останавливается. Добавляют фреон, летом стравливают.
Areso
30.06.2026 10:12Охлад, который сделан без резервов - такое. Это значит, что при нормальной эксплуатации стоит паре узлов выйти из строя и выйдет точно тоже самое.
ИМХО, здесь проблема в том, что заявлена надежность (хостером), которую не может дать площадка.
TemArtem
30.06.2026 10:12Жара в 30 градусов для Нидерландов это давно не аномалия, а обычное лето. Дата-центры обязаны проектироваться с запасом под такие пики
Dmitry_604
30.06.2026 10:1246 часов простоя в Амстердаме
Там да, достаточно зайти не в ту дверь - и "потерял" несколько дней :))
Areso
30.06.2026 10:12Быстрый Гуглеж не дает подтверждений, что площадка была сертифицирована как Tier III.
А значит, хостер "приврал".
А что площадка обещала хостеру, мы вообще не знаем =)
TemArtem
30.06.2026 10:12База аренды стоек у провайдера третьего эшелона под видом премиум-услуги. Экономия на резервных чиллерах всегда вылезает боком при первых же серьезных нагрузках на сеть
SNL_KLA
30.06.2026 10:12Тоже надоела эта ситуация.
Понимаю что в текущих реалиях не все хотят работать с компаниями из России, но все же.
После переезда подняли ценник, при этом я не могу пользоваться услугой.
Посмотрел на этот ЦОД Купрум на панорамах - располагается в складском кластере. Никаких ДГУ снаружи не нашел, внутреннее расположение тоже вряд-ли, нет выхлопных труб и приточной вентиляции. Сколько-нибудь серьезных внешних блоков систем охлаждения так же не нашел.
Натуральная шарага, не удивительно что охлаждение там постоянно отваливается.
Удивительно, то что Таймвэб решили разместиться в таком месте.
shut-down-now
30.06.2026 10:12просто выпал critical miss.
понять-простить.
у меня на таймвебе есть 1 vps за лет 5 uptime 100%.
theext4
30.06.2026 10:12Моя претензия — конкретная и узкая: кластер отказов питания и охлаждения в ДЦ Qupra в мае–июне 2026 года. Это не хакеры. Это инженерная инфраструктура площадки, за которую отвечает хостер. И именно она сыпалась раз за разом.
Хостер не может отвечать за питание и охлаждение в арендованном ДЦ, хостер только размещает серваки и прочее оборудование, или арендует их. Но выбор ДЦ явно неудачный, в прошлом ДЦ такого вроде бы не было.
Areso
30.06.2026 10:12Хостер отвечает за услугу перед клиентами, за питание и охлаждение отвечает ДЦ.
Если ДЦ не хочет или не может соответствовать стандартам хостера, то меняют или ДЦ, или понижают стандарты хостера (что, кстати, тоже возможно).
Sebasy
30.06.2026 10:12Облачный сервер в той же зоне, ситуация такая же. За последний месяц > 30 часов простоя по разным причинам.
130837
30.06.2026 10:12На том же firstbyte все прекрасно работает… или они с другим дс договорились?)
x86chk
30.06.2026 10:1246 часов суммарно... 28 суток подряд (и всё ещё лежат!) во втором ДЦ у VDSina, и они ещё Tier IV.
Скриншот с лендинга vdsina.com Но они не говорят, в какой именно локации в Нидерландах находились VPS.
SilverHorse
30.06.2026 10:12За новостями следить надо... они не "лежат", в ДЦ там пришли вежливые люди и оборудование сейчас ждет перевозки на новое место на складах.
kuza2000
30.06.2026 10:12Таймвеб я использовал в 2012 году и очень понравился. В то время, ИМХО, это был лучший провайдер. Поэтому и сейчас взял VPS там. По принципу "недешево, но лучшее же"... Но уже который раз авария многими часами. С утра сервер лежит... начинаю разочароваться и думать, куда перейти... ((
Ioanna
30.06.2026 10:12У меня есть проекты на обоих упомянутых хостингах - OVH и Timeweb Cloud. Склоняюсь к решению, противоположному тому, что в статье, - уйти от OVH к Timeweb. Слишком трудоемкие пляски с бубном при ежемесячной оплате хостинга зарубежной картой, которая может в любой момент накрыться.
obbana
30.06.2026 10:12Это проблема не хостинга, а датацентра. Зацепило многих хостеров, кстати... Интересно, что же там случилось, пока информации не вижу.
Talos13
30.06.2026 10:12Timeweb CloudFirstVDS и кто еще в купре сидит - всем было бы гораздо легче если бы вы хотя бы писали что происходит в данный момент. Ждём новые чиллеры, налаживаем систему охлаждения, пытаемся разобраться почему всё легло. Неужели купра настолько безответственные что не держат вас в курсе происходящего?
Судя по всему, вам и манагеры купры дают разную информацию. 1вдс до 15:00 по мск обещали инфу, таймвеб до 17:00. 17:30 - у всех всё лежит. Раз уж ЧП - не может один по связям с общественностью просто вести централизованный лог событий в цоде? Хотя бы передавать что купра говорит. Иначе что, сидеть просто ждать у моря погоды?
Timeweb_Cloud
30.06.2026 10:12@masasibata
Спасибо за вопросы — они закономерны после серии инцидентов.Начнем с главного. Сейчас на площадке идут аварийно-восстановительные работы системы охлаждения. Мы на постоянной связи с ее инженерами и публикуем обновления, как только они появляются.
Теперь по тому, что вы написали.
Про майский постмортем. Он задержался, и это справедливое замечание. К сожалению, мы зависим от данных партнера, и публиковать технический разбор с догадками вместо фактов считаем неправильным. Сейчас добиваемся полного отчета. Как только он будет у нас — опубликуем постмортем с нашими выводами.
Про компенсации. По SLA компенсация оформляется по обращению: в течение 30 дней после инцидента достаточно создать тикет в панели или написать на info@timeweb.cloud. Более подробно можете ознакомиться по ссылке: https://timeweb.cloud/records.
И самый важный вопрос — останемся ли мы на площадке. После этой серии мы уже пересматриваем стратегию по локации и параллельно оцениваем альтернативы. Обещать то, что пока не можем гарантировать, не станем, но эта ситуация для нас повод принимать решения, а не ждать очередного отчета от партнера.
Понимаем, что доверие возвращают не комментарии, а стабильная работа инфраструктуры. Поэтому наша задача сейчас — завершить инцидент и добиться от площадки гарантий, которые снизят риск его повторения. Если их не будет, то мы примем меры по переезду с площадки.
Planet_Dust
30.06.2026 10:12А почему нет хотя бы почтовой рассылки? Приходится ползать по ЛК и мониторить отдельно.
masasibata Автор
30.06.2026 10:12Спасибо что ответили хотя бы тут. В чате с вашей стороны тишина, хотя в админах сидит куча сотрудников. Он уже заполнен мемами про вас и ДЦ.
Раз уж заговорили за чат. Зачем вы убрали ссылку на него из канала с алертами? Ночью закрыли чат, а после утром включили слоумод на 1 час? Сообщения чистите. Вы же не успокаиваете людей этим, а наоборот драконите. Клиенты хотят связи со стаффом, объяснений. Более 20-и часов их проекты стоят.
Все-таки ваш ответ по инциденту в мае меня не устроил. Что было сделано с охлаждением? Как была устранена проблема в мае, в чем она заключалась и почему повторилась в июне? Не поверю что спустя месяц у вас нет информации об этом инциденте и вы не можете дать инфу в канал.
Ваши компенсации ничего не закроют. Прошло уже 20 часов, и мы уверенно шагаем ко всем 24. Такой даунтайм для любого проекта - подобно смерти. Мы теряем клиентов, репутацию, прибыль. Лично для меня даже компенсация эквивалентная аренде вашего сервера на ГОД не покроет мои потери.
Большинство уже пришло к выводу, что нужно переезжать. И они к этому готовы, единственное что осталось - чтобы проблема была устранена в Qupra и сервера поднялись. В тот же миг все делают бекапы и дружно переезжают к другим хостерам, после чего удаляют у вас сервера. Не думаю что у вас получится вернуть этих клиентов.
Так может стоит все-таки выйти на связь с людьми в чате, убрать слоумод и дать им высказаться, попутно отвечая на их вопросы, а не отмалчиваясь? Мы понимаем что проблема в ДЦ, но ваш выбор пал на этот ДЦ. Клиенты платят вам за услугу, за заявленный SLA, чего в итоге и близко не получают. При этом цены у вас действительно высокие относительно рынка.Areso
30.06.2026 10:12Лично для меня даже компенсация эквивалентная аренде вашего сервера на ГОД не покроет мои потери.
При ваших потерях за день больше, чем стоит ваша же инфраструктура за год, есть смысл закладываться в гео-распределенные решения, иначе и новый хостинг рано или поздно выиграет в рулетку.
monamonax
30.06.2026 10:12У меня, как и у других коллег по несчастью, объективная претензия одна - не информативность всей ситуации, без вменяемой станицы состояния, алерты в запрещенном телеграме, которые тоже мало о чем говорят… вместо того, чтобы выйти на диалог с клиентами, как гитлаб в свое время, просто везде все подзакрыли и помалкиваете… народ нашел рупор сначала в идеях но и их закрыли… поэтому сюда все перешло…
П.с. Чукча не писатель - чукча читатель…
prishelec
30.06.2026 10:12Я использую хостинг от allhostings
У меня хостинг на сервере в Нидерландах. За последние полгода были кратковременные сбои. А в ночь с субботы на воскресенье (я после трех ночи) произошло что-то масштабное (а может и субботним вечером).
Сервер заработал только сегодня. Где-то в часов 15 +/-.
GoldCode
30.06.2026 10:12SLA это не гарантия аптайма, это просто прейскурант, по которому хостер покупает право лежать
Domi_sama
30.06.2026 10:12Что ж сказать? Ребята не выдержали и из-за шквала критики и кучу мемов походу снесли свой тг канал подчастую... мдаааа)
andreymal
30.06.2026 10:12Всё на месте, это у вас что-то глюкнуло
IvUyr
30.06.2026 10:12Выше писали, что за упоминание этой статьи банят в чате… Может @Domi_sama (случайно?) попал под раздачу плюшек…
Sterhel
Сервак там же.
Минус — заколебало вкрай, конечно, хотя я и осознаю трёхбуквенные нюансы.
Плюс — за предыдущие такие случаи «полдня без сервака, охлаждение не осилило» они сделали перерасчёт и накинули бесплатных дней на баланс.
masasibata Автор
Не совсем понимаю, почему это считается плюсом. Перерасчет за период, когда услуга фактически не предоставлялась, это скорее минимальная обязанность провайдера, а не бонус.
Проблема ведь не в стоимости нескольких дней аренды. Пока сервер недоступен, у многих стоят коммерческие проекты: интернет-магазины, CRM, SaaS, боты, корпоративные сервисы. В этот момент теряются клиенты, деньги и репутация. Никакие несколько бесплатных дней аренды этого не компенсируют.
Поэтому для большинства важнее не перерасчет после очередного простоя, а чтобы таких простоев в принципе не происходило.
Sterhel
— Не совсем понимаю, почему это считается плюсом.
Потому что никуда не делись хостеры (и вообще компании), которые и за пару дней простоя не накинут дней сверху и даже не извинятся в чатике саппорта. Так что да, увы, формальное соблюдение хоть каких-то договорённостей я склонен считать плюсом.
Но в плане AMS я тоже думаю сменить провайдера. Ибо он всё ещё лежит со вчерашнего вечера.
Sterhel
Ну и да.
— у многих стоят коммерческие проекты: интернет-магазины
ИМХО события последнего времени в плане «давайте обрубим любые возможности юзать ***» неслабо так намекают, что держать серьёзные коммерческие проекты и прочее на нидерландских серваках — как минимум, не очень разумная затея.
Arhammon
Тут некоторые хостеры вообще на пару недель отвалились... если рамки только отечественных хостингов за рубежом, то боюсь "надо отнестись с пониманием"... надежность вообще во многом лимитирована тем с какой ноги завтра встанет отечественный или зарубежный чинуша.
TemArtem
Компенсация в пару сотен рублей за сутки простоя выглядит как издевательство, когда бизнес теряет сотни тысяч на неработающих кассах
select26
При таких суточных потерях не иметь резерва - хреновый это бизнес, и IT у него хреновая.
Единичный отказ любой компоненты инфраструктуры - это не авария! Если не так - вы неправильно погстроили инфраструктуру. Деды так учили.
Kovurr
Потому что можно сделать как https://the.hosting/ru/ Прислать письмо: "мы не смогли и закрываемся" и свалить в закат, вместе со всеми деньгами юзеров в личных кабинетах. При этом они отключили систему тикетов, т.е. написать им с просьбой вернуть оставшиеся на счету деньги - невозможно.
atuirin
Для критикал сервисов должна быть межцодовая кластеризация, хотя бы active-passive, ибо упал весь ДатаЦентр в Амстердаме не только timeweb затронут, другие перекупы тоже отвалились, тот же hostkey например. Я не понимаю наезда на конкретно таймвеб, а давайте всех в шеренгу поставим и расстреляем? И что с голландцами, в их сторону что-то не увидел вентиллятора.
masasibata Автор
Так я и не говорю, что виноват только Timeweb. Понятно, что если лег Qupra, то задело всех, кто там размещается.
Но проблема в том, что это уже не первый раз. Такое уже было в мае. Тогда тоже говорили, что занимаются охлаждением, обещали постмортем, обещали разобраться. В итоге постмортема нет, а спустя месяц мы снова видим практически ту же самую историю. Вот это уже и вызывает вопросы.
И если честно, меня не особо волнует, что там произошло у голландцев. Я не клиент Qupra, я клиент Timeweb. Именно Timeweb продает мне услугу, пишет про Tier III, высокий uptime и берет за это деньги. Соответственно, и вопросы у меня к Timeweb.
Если дата-центр систематически становится причиной таких простоев, значит с ним нужно что-то делать. Потому что для клиента совершенно неважно, чей именно кондиционер перестал работать. Важно только одно: сервис снова лежит.
Areso
Во-первых, голландцы предоставляют услуги не автору, а Таймвебу
Во-вторых, что более важно, голландцы на странице ДЦ нигде Tier III не обещали. И вообще слово Tier я у них не нашёл =)
fluid_panda
Был сервер там же. Служба поддержи на мой взгяд ужасная: человек отвечает в течение суток, получается лаг между сообщениями примерно в 24 часа, что как-то многовато.
По собственной глупости завел аккаунт с указанием почты на protonmail, как оказалось, они не могут работать с этой почтой, проверяющие ссылки туда не уходят. Аккаунт оказался недоступным. А через почту до них не получилось связаться, они ее, либо не читают, либо игнорят. Только благодаря тому, что я оплатил длительный период, у меня оставался доступ к серверу. Но после того, как он отвалился (ams локация), я не думая перешел на другого провадера.
И если честно, я бы не рекомеандовал таймвеб, хотя бы из-за того, как работает служба поддержки.