Инциденты Timeweb Cloud в 2026 году

Ичи29.09.2026Около 7 минОколо 2009 слов

Инциденты Timeweb Cloud в 2026 году

30 сентября 2026 года добавлено наблюдение live-панели по msk-1. Это дата чтения статусов компонентов, не установленное начало аварии. Связь с прежними сообщениями № 410–413, причина и длительность текущей деградации не установлены. История ниже сохраняет прежние даты проверок.

18 сентября 2026 года добавлен отдельный блок пользовательских VPS-сигналов от 15–16 сентября. Их принадлежность Timeweb Cloud и связь с официальными сообщениями № 410–413 не установлены; календарная дата официального Major этим дополнением не уточняется.

17 сентября 2026 года повторно прочитан публичный канал оповещений и добавлена пропущенная последовательность сообщений № 410–413 о Major msk-1. Это дата проверки, не установленная дата аварии. Более ранняя хронология сохранена по проверке 27 августа.

Наблюдение 30 сентября — статусы `msk-1`

В прочитанном 30 сентября 2026 года состоянии официальной live-панели для msk-1 показаны разные статусы:

Компоненты	Отображаемый статус
Облачные серверы, Kubernetes, облачные базы данных, App Platform, балансировщик нагрузки, маршрутизируемые сети	Деградация
Обычная сеть, сетевые диски, бэкапы `msk-1`; панель управления	Доступны

Это подтверждение того, что сообщил интерфейс провайдера, не результат собственного HTTP/TCP-теста и не доказательство отказа каждого ресурса зоны. В доступном представлении нет надёжного идентификатора текущего события, точного начала, причины или финального сообщения. Поэтому не рассчитываем downtime и не приписываем текущие статусы старым alert № 410–413. В датированную хронологию аварий ниже новое событие с неизвестным началом не добавлено.

Для сопоставления с собственным инцидентом нужны зона и продукт конкретного ресурса, временная шкала внешних проб и ответ поддержки. После появления официальной карточки уточните эту запись, а не создавайте по одной «аварии» на каждую дату проверки. Категория «Рискованные / спорные» сохраняется; из этой панели не следуют потеря данных, общая недоступность всех зон или сбой обычного Timeweb-хостинга.

Проверка 17 сентября: Major `msk-1`, сообщения № 410–413

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

Сообщение	Подтверждённое содержание
№ 410	Major, `msk-1`: недоступна часть сервисов в Москве
№ 411	Недоступен роутер в Москве, выполнено переключение на резерв; возможна частичная недоступность других зон РФ
№ 412	Продолжалось восстановление control plane после холодного рестарта
№ 413	Инцидент закрыт; сеть восстановлена в 12:55 МСК, оборудование заявлено работающим штатно

В доступном текстовом представлении канала не извлечена календарная дата этих четырёх публикаций. Поэтому событие пока не внесено под выдуманной датой в датированную таблицу, не объявлено произошедшим 17 сентября и не снабжено рассчитанной длительностью. Часы интерфейса Telegram без подтверждённого часового пояса не используются как начало воздействия.

Это подтверждённое провайдером событие с неполной временной атрибуцией. Сетевой отказ и восстановление управления не объединяются с апрельской СХД или августовским ams-1; общая причина не установлена. Полный охват клиентов и целостность их данных отдельно не проверялись. Зелёная live-панель после закрытия не отменяет сообщения об аварии.

Для завершения временной шкалы требуется проверить календарную дату сообщений № 410–413 в оригинальном Telegram-представлении или датированном официальном отчёте. Эксплуатационные измерения не проводились; независимая резервная площадка и мониторинг приложения нужны отдельно от status-панели.

15–16 сентября — пользовательские сообщения о VPS

Источник — комментарии Detector404 о Timeweb, прочитанные 18 сентября. Страница объединяет бренд, а не гарантированно один продукт. Упоминание VPS без аккаунта, тарифа или hostname не доказывает принадлежность Timeweb Cloud; эти сигналы не включены в подтверждённую хронологию.

Дата публикаций, 2026 год	Сообщения пользователей	Подтверждение
15 сентября, 12:02–13:15	Серия сообщений о недоступных VPS, серверах и сети; в 12:29 пользователь упоминает московский роутер	Пользовательские сигналы; слова о роутере не являются официальным RCA
16 сентября, 13:54	VPS не отвечает	Пользовательский сигнал; зона и причина неизвестны

Часы приведены как в интерфейсе источника, без присвоения неподтверждённого часового пояса. Это интервалы публикаций, не измеренные начало и конец аварии; отдельное сообщение 16 сентября не доказывает непрерывность с предыдущим днём.

Симптомы могут напоминать официальную последовательность msk-1 № 410–413, но их совпадение не устанавливает календарную дату этих официальных публикаций или общую причину. Для сопоставления нужны оригинальные временные метки Telegram, зона/ресурс клиента и ответ поддержки. Не считаем комментарии независимыми техническими измерениями и не рассчитываем по ним SLA.

Сообщения о сайтах 16–17 сентября сохранены отдельно в журнале обычного Timeweb-хостинга, тоже с оговоркой о неподтверждённом продукте. Новые сигналы сами по себе не меняют категорию Timeweb Cloud.

Краткий вывод

В 2026 году у Timeweb Cloud совпали разные классы риска:

критическая деградация сетевого хранилища;
крупные DDoS-атаки;
повторные проблемы охлаждения внешнего дата-центра в Амстердаме;
потеря связности de-1 из-за аварии промежуточного узла Equinix FR5;
отдельный сетевой сбой оборудования в ams-1 25 августа;
кратковременные локальные деградации.

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

При проверке 27 августа официальная live-панель показывала облачные серверы и основные сервисы доступными. Это текущий статус, а не отмена истории инцидентов.

Хронология

Дата	Локация или сервис	Симптомы	Причина	Статус	Источник
25 августа	`ams-1`, Нидерланды	Major-инцидент: сервисы в локации стали недоступны по сети	Сетевое оборудование перестало отвечать; провайдер отправил его в принудительную перезагрузку	Первый alert — 16:10 МСК; сеть восстановлена в 16:18; запись закрыта в 16:33	Официальный канал
19 августа	`spb-1`, `spb-3` и зависимые сервисы	Утром live-панель показывала частичную доступность; позднее все сервисы отображались доступными	Не опубликована	Восстановлено при повторной проверке	Официальная live-панель
15 августа	`de-1`, Германия	Major-инцидент: потеря сетевой связности с площадкой, на которой размещены серверы Timeweb Cloud	Протечка системы охлаждения на промежуточном телеком-узле Equinix FR5 привела к перегреву и массовому отключению сетевого оборудования	Связность восстановлена; финальное закрытие опубликовано в 23:38 МСК	Официальный канал
29–30 июня	`ams-1`, Qupra	Повторная недоступность серверов и восстановительные работы	Отказ системы охлаждения дата-центра	Восстановлено на внешнем чиллере	29 июня, 30 июня
26 июня	`ams-1`	Major-инцидент и нарушение доступности	Проблемы дата-центра и охлаждения	Устранено	Официальный канал
25 июня	Несколько зон	Деградация сети во время атаки заявленной мощностью до 3 Тбит/с	DDoS	Устранено	Официальный канал
5–7 и 21–25 июня	Российские зоны	Серия сетевых деградаций и усиление фильтрации	DDoS-атаки	Устранено	Официальная live-панель
9–10 апреля	`MSK-1`, сетевое хранилище	Высокая задержка дискового ввода-вывода, зависание части ВМ в `I/O wait`, ограничения операций управления; отдельные полные паузы I/O доходили до 30 минут	Программный дефект низкоуровневого кода СХД вызвал циклические перезапуски узлов и перегрузку шины данных	Кластер стабилизирован 10 апреля; целостность данных сохранена	Технический отчёт Timeweb Cloud

25 августа — сетевое оборудование `ams-1`

В 16:10 МСК Timeweb Cloud опубликовал Major-alert о сетевой недоступности сервисов в Нидерландах.

В 16:20 провайдер уточнил, что сетевое оборудование перестало отвечать и было отправлено в принудительную перезагрузку. Финальное сообщение указывает, что сетевая доступность фактически восстановилась в 16:18, а оборудование после проверки работало штатно. Запись была окончательно закрыта в 16:33.

16:10 — первый публичный alert
16:18 — заявленное время восстановления сети
16:20 — опубликовано техническое уточнение
16:33 — инцидент закрыт

Это не даёт оснований утверждать, что простой длился ровно восемь минут: фактическое воздействие могло начаться до первого сообщения, а у разных клиентов отличаться.

Событие отличается от июньских проблем Qupra:

в июне причиной называлось охлаждение внешнего дата-центра;
25 августа перестало отвечать сетевое оборудование;
оба класса проблем затронули ams-1, но не должны объединяться в одну причину.

15 августа — потеря связности `de-1` через Equinix FR5

15 августа произошёл Major-инцидент во Frankfurt-направлении.

Timeweb Cloud сообщил, что авария случилась не на площадке с пользовательскими серверами, а на промежуточном узле Equinix FR5, через который проходили каналы связи до de-1.

По опубликованному обновлению:

в системе охлаждения машинных залов FR5 обнаружили протечку;
температура поднялась выше 50 °C;
сработала противопожарная система;
сетевое и операторское оборудование начало отключаться;
серверы и данные Timeweb Cloud на целевой площадке не были повреждены;
пользователи потеряли сетевую связность до работающего оборудования.

Опубликованный провайдером таймлайн по МСК:

05:33 — первые потери пакетов на линках через FR5
05:41 — обнаружена протечка системы охлаждения
06:32 — зафиксирован рост температуры в залах
07:25 — критическая температура и массовые обрывы связи
19:34 — питание на часть стоек операторов ещё восстанавливалось
23:38 — связанность с площадкой восстановлена, инцидент закрыт

Нельзя считать всё окно с 05:33 до 23:38 одинаковым непрерывным простоем каждого сервера. Но событие показывает важный класс отказа: сервер может быть исправен, а сервис недоступен из-за промежуточного узла и общей трассы операторов.

Практический вывод по `de-1`

резерв в том же городе не гарантирует независимый маршрут;
health-check должен идти через несколько операторов;
резервная площадка должна иметь независимый network path;
DNS failover должен быть заранее проверен;
внешние backup и secrets должны быть доступны без de-1;
нужно различать повреждение сервера и потерю сетевой связности.

19 августа — частичная доступность в Санкт-Петербурге

Утром на live-панели наблюдалась частичная доступность облачных серверов и связанных сервисов в зонах spb-1 и spb-3. При повторной проверке все зоны уже показывались доступными.

Исторической записи с причиной и длительностью на публичной странице не найдено, поэтому событие отмечено как наблюдение live-панели, а причина не предполагается.

9–10 апреля — критическая деградация СХД в MSK-1

По опубликованному провайдером техническому отчёту, 9 апреля в 19:39 началась критическая деградация сетевого хранилища в зоне MSK-1. У части виртуальных машин выросла задержка дисковых операций, процессы зависали в состоянии I/O wait, а некоторые операции управления серверами временно блокировались.

Причиной назван программный дефект в низкоуровневом коде СХД. Он запускал циклические перезапуски узлов хранения и создавал дополнительную нагрузку на шину данных. К 10:30 10 апреля кластер был стабилизирован, после чего восстановительные операции продолжались примерно до 17:30.

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

Июнь — DDoS и аварии Qupra

Июньские события относятся к двум независимым группам:

атаки на сеть и инфраструктуру Timeweb Cloud;
инженерные проблемы площадки Qupra в зоне ams-1.

Провайдер отдельно сообщал о перегретом дата-центре, проблемах подрядной площадки и поиске варианта миграции. Защита сети не решает отказ охлаждения, а резервирование внутри одного проблемного ЦОД не заменяет внешнюю площадку.

Источник: Timeweb — «Про перегретый дата-центр».

Обычный Timeweb-хостинг — отдельный продукт

Инциденты shared-хостинга не переносятся в этот журнал, а события Cloud нельзя автоматически приписывать обычному хостингу.

Инциденты обычного Timeweb-хостинга

Влияние на оценку провайдера

Timeweb Cloud остаётся в категории «Рискованные / спорные».

Август добавил два разных Major-события в европейских направлениях:

15 августа — внешний промежуточный узел FR5 и потеря связности de-1;
25 августа — зависшее сетевое оборудование ams-1.

Сильные результаты личных тестов производительности не заменяют анализ повторяемости и типов отказа. Добавленные сообщения msk-1 учитываются отдельно; неполная календарная атрибуция не превращена в точную метрику downtime.

Практический вывод

держать резервные копии вне Timeweb Cloud и вне той же площадки;
иметь план переключения на другой регион или провайдера;
мониторить приложение, сеть, базу данных и дисковую задержку отдельно;
проверять контрольное чтение/запись, а не только ping VM;
не считать одну исправную площадку гарантией доступности промежуточного маршрута;
фиксировать конкретную зону и время, пока live-панель не изменилась;
различать время восстановления и время закрытия status-записи;
не смешивать Timeweb Cloud с обычным shared-хостингом.

Инциденты Timeweb Cloud в 2026 году

Описание