Разработчик уходит из Timeweb Cloud после 46 часов простоя в Амстердаме

01 июл 2026, 12:23

Почему я ухожу из Timeweb Cloud: 46 часов простоя в Амстердаме за два месяца

Два месяца назад я перенес свой проект на облачные серверы Timeweb Cloud в дата-центре Амстердама. Думал, европейское качество — это надежно. Вместо этого получил 46 часов простоя. Это не сбой, а системная проблема. За май-июнь 2025 года инфраструктура упала дважды, и поддержка просто разводила руками. Ниже — хроника моего фиаско, честное сравнение с альтернативами и инструкция, как не попасться на удочку красивых SLA.

46 часов за два месяца: как это было

Первый звонок прозвенел 14 мая. В 11 утра по Москве сервер просто исчез. Мониторинг Pingdom показал: 22 часа 17 минут полной недоступности. Timeweb в своем статус-пейдже подтвердил проблему с сетевым оборудованием в дата-центре Amsterdam-1. Я выдохнул — бывает. Через две недели, 29 мая, история повторилась. Еще 24 часа 10 минут. Итого: 46 часов 27 минут за два месяца.

Хостер опубликовал отчет: аварийное отключение коммутатора и DDoS-атака на upstream-провайдера. Звучит весомо. Но вот что важно: их SLA для облачных серверов обещает 99,99% доступности. Это 52 минуты простоя в год. По факту за два месяца аптайм составил 96,8%. Это уровень дешевого shared-хостинга, а не enterprise-облака. Гарантии SLA, кстати, распространяются только на сеть и электропитание. Если проблема в виртуализации или ПО хостера — компенсацию вы не увидите.

Реальность против обещаний: что скрывает SLA Timeweb Cloud

Я внимательно изучил публичную оферту Timeweb. Там черным по белому: для тарифов Cloud Servers гарантируется 99,99% доступности. За каждый час недоступности сверх лимита — 1% от стоимости услуг, но не более 10% в месяц. За 46 часов мне должны были начислить 46% компенсации — это чуть более 2000 рублей. На деле поддержка ответила, что инциденты признаны форс-мажором, и предложила скидку 5% на следующий месяц. Типичная ситуация: SLA — это маркетинговый инструмент, а не гарантия. Мой совет: всегда читайте раздел «исключения». Особенно про «плановые работы» и «действия третьих лиц». Там часто прячутся лазейки.

Личное наблюдение автора: Недавно я заметил, что многие провайдеры публикуют красивые цифры аптайма, но не показывают статистику по конкретным дата-центрам. Timeweb — не исключение. Если у вас нет ресурсов на мониторинг 24/7, выбирайте хостера с автоматическими кредитами и прозрачным SLA. Иначе вы рискуете остаться с отписками.

Сравнение: Timeweb Cloud против реальных альтернатив

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

Средний аптайм (2 мес.): Timeweb Cloud — 96,8%; Hetzner (EU) — 99,98%; DigitalOcean — 99,99%; Selectel — 99,95%.
Стоимость VPS 2 vCPU / 4 GB: Timeweb Cloud — ~1200 руб/мес; Hetzner — ~900 руб/мес (€10); DigitalOcean — ~1500 руб/мес ($18); Selectel — ~1400 руб/мес.
Скорость поддержки: Timeweb Cloud — 1-3 часа в тикете; Hetzner — 10-30 минут (24/7); DigitalOcean — 15-40 минут; Selectel — 30-60 минут.
Наличие NL/DE дата-центров: Timeweb Cloud — да (1 в Амстердаме); Hetzner — да (6 в Германии, Финляндии); DigitalOcean — да (Амстердам, Франкфурт); Selectel — нет (только РФ).
Реальная компенсация по SLA: Timeweb Cloud — формальная (отписки); Hetzner — автоматические кредиты; DigitalOcean — автоматические кредиты; Selectel — ручной расчет.

Цифры говорят сами за себя. Timeweb Cloud проигрывает по всем фронтам, кроме цены. Но экономия в 300 рублей в месяц не стоит 46 часов простоя.

Почему я ухожу и куда

После двух сбоев мой бизнес потерял часть клиентов и репутацию. Доверие к провайдеру, который не может обеспечить даже 99% аптайма за два месяца, подорвано. Я выбрал Hetzner. Их немецкие дата-центры славятся стабильностью, а цены ниже. Важный нюанс: для проектов с аудиторией в РФ придется настраивать CDN или прокси. Но это лучше, чем постоянные простои. Я уже перенес все сервисы: фронтенд через Cloudflare, бэкенд — на выделенный сервер за €30/мес. За месяц аптайм 99,99% без единого сбоя.

Советы тем, кто выбирает хостинг

Не повторяйте моих ошибок. Вот короткая инструкция, как не прогореть на облачном провайдере.

Проверяйте статус-пейдж. Хостер должен вести историю инцидентов. У Timeweb она есть, но, как показала практика, толку мало.
Тестируйте 30 дней. Возьмите тестовый сервер на месяц и поставьте Real User Monitoring. 46 часов за два месяца выявляются уже через месяц.
Читайте SLA. Обращайте внимание на исключения и процесс компенсации. Если там написано «по усмотрению компании» — бегите.
Имейте план Б. Настройте автоматическое переключение на резервный сервер у другого провайдера. Это не дорого, а спасет проект.

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

По материалам: Tehnoseo