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

• Карточка IONOS
• Все инциденты 2026 года
• Официальная status-панель
• DBaaS migrations и дедлайны 2026

3 октября 2026 года выборочно проверены два события от 2 октября: ограничение телефонной поддержки остаётся в Identified, а DCD объявлен восстановленным в 21:28 UTC. Финал DCD прочитан на общей панели; отдельная карточка в доступном представлении содержит только первоначальное сообщение. Таблица и подробный раздел согласованы; прежние события сохраняют даты своих проверок.

30 сентября 2026 года добавлены три закрытые записи от 29 сентября: Managed Kubernetes и два отдельных отказа AI Model Hub API. Проверены постоянные карточки. Для нового Kubernetes-инцидента провайдер предупреждал также о возможной недоступности работающих приложений; это отличается от события 23 сентября. Ранее сохранённые даты проверок и история других сервисов не переаттестованы.

26 сентября 2026 года добавлены финальное закрытие Managed Kubernetes, отдельный TXL-инцидент 24 сентября и уже закрытый DCD-инцидент 26 сентября. Для TXL и DCD финальные сообщения прочитаны на общей панели, тогда как отдельные карточки в доступном представлении отставали. Старые проверки сохранены; это не полный повторный аудит журнала.

24 сентября 2026 года добавлено событие Managed Kubernetes от 23 сентября. Проверены сообщения общей официальной панели; отдельная карточка не загрузилась. Остальные события этим дополнением не переаттестованы.

22 сентября 2026 года выборочно добавлены финальные закрытия TXL и GPU capacity от 21 сентября. Источник — свежие сообщения общей официальной панели; отдельные карточки в доступном кэше ещё показывали прежние статусы. Остальная история сохраняет даты предыдущих проверок.

Последняя выборочная проверка TXL, RCA S3 и Cloud Support: 10 сентября 2026 года. DBaaS-дедлайны проверены 7 сентября. Более ранняя хронология сохранена из предыдущих проверок.

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

В 2026 году у IONOS Cloud заметны несколько разных классов проблем:

1. деградации data plane — повышенная задержка чтения и записи S3 Object Storage;
2. деградации управляющего слоя — Managed Kubernetes, Cloud API, Data Center Designer, Object Storage management и IP management;
3. повышенные ошибки и задержка AI Model Hub;
4. ограничения ёмкости, когда существующий сервис работает, но создать или повторно запустить ресурс нельзя;
5. scheduled migrations/deprecations managed services, которые требуют действий клиента, но сами по себе не являются авариями;
6. ограничение доступности поддержки, которое может затруднить восстановление без отказа инфраструктуры.

Для production это разные риски. Нельзя складывать их в один показатель «аптайм IONOS» и нельзя автоматически считать всё окно status-записи простоем каждого workload.

TXL переведён в Resolved 21 сентября в 07:24 UTC, после восстановления сервисов ещё 9 сентября. В 08:31 UTC 21 сентября объявлено расширение GPU capacity и восстановление обычной доступности provisioning GPU Server. Для закрытого S3-инцидента ранее опубликован RCA; сентябрьские ограничения Cloud Support закрыты. Новая запись телефонной поддержки от 2 октября на проверку 3 октября ещё открыта. Подробные временные рамки и границы воздействия приведены ниже.

2 октября — телефонная поддержка и отдельный сбой DCD

Проверено 3 октября 2026 года. Все временные отметки источников ниже — UTC.

Cloud Support: увеличенное ожидание по телефону

Карточка ограничения содержит Identified 2 октября, 13:55 UTC: возможны периоды увеличенного ожидания телефонного ответа. IONOS предлагает DCD Form или email. На проверку 3 октября финального сообщения нет; причина, точное начало воздействия и фактическое время ответа каждому клиенту не установлены. 13:55 — время публикации, не измеренное начало деградации.

Это канал поддержки, а не остановка compute, сети или хранилищ. Сентябрьские ограничения остаются отдельными закрытыми событиями; их общая причина с новой записью не подтверждена.

Data Center Designer: закрыто 2 октября

На общей панели опубликованы Investigating 20:16 и Resolved 21:28 UTC 2 октября. По Екатеринбургу это 3 октября, 01:16–02:28 (UTC+5). Между сообщениями — 72 минуты, не доказанный простой всех VM. Отдельная карточка DCD в прочитанном представлении ещё показывает только первое сообщение; финал взят из более позднего обновления общей панели.

Причина и отказ других API или клиентских ресурсов не заявлены. Не объединяйте DCD и поддержку в один инцидент. На случай недоступности DCD заранее сохраните email поддержки и независимый способ управления. Категория «Рискованные» сохраняется; собственных тестов ресурсов и обращений в поддержку не выполнялось.

29 сентября — Kubernetes и два отказа AI Model Hub API

Все отметки ниже — UTC, дата повторной проверки — 30 сентября.

Managed Kubernetes: не только управление

Официальная карточка содержит Identified 07:48, сообщения 09:42 / 09:47, Monitoring 11:07 и Resolved 14:09. Перечислены Managed Kubernetes в FR/PAR, US/MCI, DE/TXL, DE/FRA, GB/LHR, US/EWR, US/LAS, ES/VIT и GB/BHX.

В обновлениях провайдер предупреждает о возможных нарушениях работы клиентских приложений, включая недоступность уже запущенных сервисов, а также deploying, scaling и Kubernetes API. Поэтому нельзя переносить сюда формулировку «workloads не затронуты» из инцидента 23 сентября. 6 ч 21 мин — интервал публикаций, а не установленный простой каждого кластера; после 11:07 шло наблюдение за исправлением. Команда сообщила об установленной причине, но подробный технический RCA в прочитанной карточке не опубликован.

AI Model Hub: две отдельные записи

Запись	Сообщение → закрытие	Опубликованное воздействие
Первый отказ	29 сентября, 09:58 → 11:07	Inference API возвращал 503 для chat, embedding, rerank и image; IONOS прямо связал это с текущей Kubernetes-проблемой во Франкфурте
Повторный отказ	29 сентября, 11:35 → 14:08	API объявлен недоступным; отдельное сообщение не уточняет техническую причину

Интервалы 1 ч 9 мин и 2 ч 33 мин не объединяются в непрерывный outage с 09:58 до 14:08. Связь первого отказа с Kubernetes — заявление провайдера; она не доказывает одинаковую причину второго отказа или сентябрьских событий других дат. Обе AI-записи относятся к Global Services / AI Model Hub, не к недоступности всех VM.

Для приложения проверяйте внешнюю доступность workload отдельно от Kubernetes API и AI API. Повторы AI-запросов должны быть ограничены по числу и общей длительности; учитывайте возможную повторную оплату и не переключайте провайдера, передавая ему данные без разрешённой политики обработки. Категория «Рискованные» сохраняется; своих измерений API, кластеров и времени восстановления здесь нет.

26 сентября — Data Center Designer

Карточка DCD описывает бесконечную загрузку интерфейса с 00:25 UTC. Доступность объявлена восстановленной в 02:57, в 03:04 продолжалось наблюдение. Общая панель уже содержит финальный Resolved 26 сентября в 11:11 UTC; отдельное представление карточки при проверке ещё показывало monitoring.

Не записывайте весь период до 11:11 как непрерывный простой: после 02:57 интерфейс был объявлен доступным. Событие относится к DCD, а не к доказанному отказу всех VM, Cloud API или баз. Для аварийного плана отдельно проверяйте рабочий API-доступ; статус других компонентов не является нашим тестом клиентского приложения.

24 сентября — потери пакетов TXL и задержки provisioning

Отдельная карточка и общая панель фиксируют сообщение о сетевой деградации 08:43 UTC, дополнение о задержках создания ресурсов 08:58, установку исправления / Monitoring 11:57 и Resolved 14:33. Финальные этапы прочитаны на общей панели; отдельная карточка при проверке содержала более ранние сообщения.

Сеть относится к TXL; список затронутых компонентов provisioning шире и сам по себе не означает сетевой отказ во всех перечисленных регионах. Это не продолжение события 8–9 сентября без подтверждённой общей причины. Разделяйте доступность уже работающих ресурсов и создание новых; после timeout проверяйте итог операции до повтора. Время жизни записи не используется как измерение SLA каждого клиента.

23 сентября — нестабильность управления Managed Kubernetes

Первое сообщение — 23 сентября в 17:15 UTC (Investigating), в 18:32 — Identified после меры против высокой storage latency. При первоначальной проверке 24 сентября финал ещё не был прочитан. Теперь карточка события подтверждает mitigation приблизительно 23 сентября в 19:00 UTC и публикацию Resolved 24 сентября в 05:43 UTC. Проверено 26 сентября.

В затронутых компонентах указан Managed Kubernetes DE/FRA. Ухудшались административные операции; работающие приложения провайдер объявлял незатронутыми. Окончание mitigation не подменяется более поздним временем закрытия записи. Технический RCA обещан, но в прочитанной карточке ещё не опубликован. Общая причина с августовским Kubernetes, S3 или TXL не установлена.

Проверяйте API управления отдельно от внешнего health-check приложения, а после timeout выясняйте результат операции перед повтором. Категория «Рискованные» сохраняется; собственных эксплуатационных тестов здесь нет.

Подтверждённые события

Дата	Сервис	Что произошло	Воздействие	Статус / источник
2 октября	Data Center Designer	Панель DCD недоступна	Интерфейс управления, не подтверждённый отказ VM или других API	Investigating 20:16, Resolved 21:28 UTC по общей панели; карточка. Проверено 3 октября
с сообщения 2 октября, 13:55 UTC	Cloud Support	Возможны периоды увеличенного ожидания по телефону; предложены DCD Form и email	Канал поддержки, не отказ инфраструктуры	На проверку 3 октября Identified; точное начало воздействия и финал неизвестны; карточка
29 сентября	Managed Kubernetes, девять перечисленных локаций	Деградация control plane; предупреждение о возможной недоступности работающих приложений	Не только управление; охват каждого workload не установлен	Identified 07:48, Monitoring 11:07, Resolved 14:09 UTC; карточка
29 сентября	AI Model Hub / Global Services	Два отдельных отказа API	Первый: 503 на chat, embedding, rerank, image; связан провайдером с Kubernetes во Франкфурте. Причина второго отдельно не уточнена	Закрыты 09:58–11:07 и 11:35–14:08 UTC; первый · второй
26 сентября	Data Center Designer	Интерфейс застревал на загрузке	Управление через DCD, не подтверждённая остановка VM	Доступен с 02:57, Resolved 11:11 UTC по общей панели; карточка
24 сентября	Сеть TXL / provisioning	Потери пакетов и задержки создания ресурсов	Сетевое качество отдельных ресурсов и управление оцениваются раздельно	Fix / Monitoring 11:57, Resolved 14:33 UTC; карточка · финал на общей панели
23–24 сентября	Managed Kubernetes, DE/FRA	Нестабильность control plane; применена мера против высокой storage latency	Административные операции деградировали, workloads заявлены работающими	Mitigation около 23 сентября 19:00, Resolved 24 сентября 05:43 UTC; карточка
8–9 сентября; закрытие 21 сентября	Сеть DE/TXL	Сетевой сбой; команда связала проблему с недавней заменой маршрутизатора	Compute, Storage, Network, Provisioning и DBaaS восстанавливались поэтапно	Resolved 21 сентября, 07:24 UTC по общей панели; карточка TXL. Monitoring после 9 сентября не равен непрерывному outage
8 сентября	Cloud Support	Отдельное повторное ограничение телефонной поддержки	Канал помощи, не вычислительные ресурсы	14:15–21:57 UTC, закрыто; история IONOS
4–8 сентября	Cloud Support	Ограничена телефонная поддержка; 7 сентября сообщалось о задержках ответов и изменениях ticketing system	Канал помощи, не вычислительные ресурсы	Resolved 8 сентября в 06:31 UTC; карточка
24 августа — 3 сентября, по RCA	S3 Object Storage, eu-central-1	Деградация операций; опубликован разбор дефекта QoS	Latency и периодические ошибки чтения; охват уточнён в RCA	Закрыто 3 сентября; RCA опубликован 8 сентября; окно публичных сообщений начиналось 26 августа и не равно периоду воздействия; карточка и RCA
23 августа	Object Storage / DCD	Buckets и Object Storage Keys не отображались в Data Center Designer; через DCD нельзя было получать, изменять, создавать и удалять buckets и keys	Управление Object Storage через DCD было недоступно; status-запись не заявляла потерю уже сохранённых объектов	Устранено; окно status-записи — 5 ч 1 мин; IONOS Cloud Status
21–23 августа	IP Reservation / DCD / API	Нельзя было резервировать или управлять IP blocks через Data Center Designer и API	Операции IP management были недоступны; уже работающие workloads не заявлены как остановленные	Устранено; окно status-записи — 57 ч 57 мин; IONOS Cloud Status
14 августа	Provisioning	Операции могли завершаться ошибкой VDC-14-1836; провайдер установил hotfix	Создание и изменение ресурсов было временно затруднено	IONOS Cloud Status
13–14 августа	AI Model Hub	Наблюдались повышенное число ошибок и увеличенная задержка API	AI-запросы могли завершаться ошибками или выполняться медленнее более суток	IONOS Cloud Status
11–12 августа	Provisioning, Cloud API, DCD	Увеличилось время обработки операций, соединения с DCD могли прерываться, Cloud API возвращал остаточные ошибки 500	Создание и изменение ресурсов было затруднено; работающие VDC-ресурсы оставались доступны	IONOS Cloud Status
4–10 августа	Managed Kubernetes	Периодическая недоступность control plane, ошибки и тайм-ауты API	Уже запущенные workloads продолжали работать; управление кластером могло быть недоступно	IONOS Cloud Status
22–23 июня	Managed Kubernetes	Из-за высокого спроса в TXL и FRA временно остановили автоматическое обслуживание, требующее временного клонирования кластеров	Плановые обновления не выполнялись до расширения ёмкости	IONOS Cloud Status
18 июня — 21 сентября	GPU Server	Из-за дефицита ёмкости создание нового GPU-сервера или повторный запуск остановленного мог завершаться ошибкой	Рекомендация не выключать работающий GPU относилась к периоду ограничения	Resolved 21 сентября, 08:31 UTC: capacity расширена; общая панель · карточка
с 12 июня	MongoDB DBaaS в de/fra/2	Playground и Business Edition нельзя было надёжно создавать из-за ограничения ёмкости	Требовалась другая локация или Enterprise Edition	IONOS Cloud Status

8–9 сентября — сеть DE/TXL

Хронология по официальной карточке; время — UTC. Финальное закрытие добавлено по общей панели при проверке 22 сентября:

Время	Сообщение
8 сентября, 23:43	Первые опубликованные сетевые alerts, первоначальный Monitoring
8 сентября, 23:56	Повторное проявление; затронуты Compute, Provisioning и Network
9 сентября, 00:20	Выявлена связь с недавней заменой маршрутизатора, применена временная мера
9 сентября, 01:07	Compute и Block Storage восстановлены; проверяется остаточное воздействие на DBaaS
9 сентября, 02:19	DBaaS восстановлен, событие переведено в Monitoring
21 сентября, 07:24	Resolved

На проверку 10 сентября финального Resolved ещё не было; теперь закрытие подтверждено более поздним сообщением общей панели. Публикация в 23:43 не является независимо измеренным началом сбоя, а monitoring до 21 сентября не означает продолжающийся полный outage. Глобальное имя компонента DBaaS в панели не доказывает отказ всех баз во всех регионах.

Для собственного восстановления проверьте отдельно сетевую связность, дисковые операции, SQL-подключения и API создания ресурсов. После timeout выясните итог операции до её повторения. Корректный health-check приложения не заменяет проверку provisioning; закрытие записи не определяет точную длительность воздействия на каждый workload.

S3 Object Storage: RCA опубликован 8 сентября

Разбор от 8 сентября, 12:26 UTC уточняет начало воздействия: 24 августа около 19:00 UTC, раньше первой публичной записи 26 августа. В FRA4 росла задержка разных S3-операций, при чтении встречались 503 и 404. Охват в RCA — клиенты с бакетами в затронутых ЦОД региона, с разной тяжестью проявлений.

Причина — дефект QoS: неравномерные обращения к redis-qos приводили к устойчивым 100% CPU и замедляли общий путь запросов. 3 сентября около 13:40 UTC провайдер отключил QoS rate limiting. Постоянное исправление поставщика ещё готовится; временно сервис работает без части QoS-функций. В плане — мониторинг размеров разделов, насыщения redis-qos, очереди compaction и проверка архитектурной изоляции. Эти меры не следует считать уже выполненными.

Исторические отметки публикаций, UTC:

Дата и время	Статус и сообщение
26 августа, 09:53	Начало публичного расследования медленных read/write
27 августа, 12:00	Статус Identified
31 августа, 17:08	Техническая причина ещё исследовалась
1 сентября, 15:18	Первые меры улучшили ситуацию для части сервисов
3 сентября, 08:27	Monitoring
3 сентября, 13:39	Resolved

Окно публикаций — 8 дней 3 часа 46 минут. Оно не заменяет уточнённый RCA период воздействия. Приблизительное время mitigation 13:40 и точная отметка публикации 13:39 сохраняются раздельно. Ошибки 404 сами по себе не доказывают безвозвратную потерю объектов.

Это data-plane performance issue, а не повтор события 23 августа в Data Center Designer:

24 августа — 3 сентября, по RCA: S3 data plane
    ↓
медленные операции через endpoint

23 августа: management plane
    ↓
buckets и keys не отображались и не управлялись через DCD

Что проверить клиенту

Synthetic monitoring должен обращаться к реальному endpoint, а не только проверять status-page:

PUT небольшого объекта
    ↓
HEAD / GET
    ↓
проверка размера и checksum
    ↓
LIST по тестовому prefix
    ↓
DELETE тестового объекта

Отдельно измеряйте:

• latency p50, p95 и p99;
• HTTP 5xx и timeout;
• скорость PUT и GET;
• ошибки multipart upload;
• время обработки media jobs;
• backup duration;
• retries и рост очередей приложения;
• поведение из разных сетей и регионов.

После восстановления сравните эти метрики с baseline, проверьте незавершённые multipart uploads, отложенные media jobs и успешность backup. Статус Resolved провайдера не заменяет проверку конкретного workload.

Для production полезны ограниченные retries с exponential backoff и jitter, idempotency там, где она поддерживается, контроль общей длительности запроса и независимая резервная копия у другого провайдера.

Сентябрь — Cloud Support: два закрытых события

Первое ограничение началось 4 сентября в 16:53 UTC. После обновления 7 сентября о нехватке покрытия и изменениях ticketing system оно закрыто 8 сентября в 06:31 UTC.

В истории IONOS есть отдельное повторное ограничение 8 сентября, 14:15–21:57 UTC; оно также закрыто. Эти записи нельзя объединять в один непрерывный отказ поддержки. На проверку 10 сентября Cloud Support отмечен как Operational.

Источник первой записи: Cloud Support.

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

IP Reservation 21–23 августа

21 августа в 07:52 UTC IONOS сообщил, что невозможно:

• резервировать IP blocks;
• управлять существующими IP blocks;
• выполнять эти операции через DCD;
• выполнять их через API.

В 08:18 UTC проблема была переведена в Identified: provider сообщил, что причина найдена и готовится fix. Финальный Resolved опубликован 23 августа в 17:49 UTC.

Между первым и финальным сообщениями прошло 57 часов 57 минут. Это длительность официального окна status-записи, а не доказанная непрерывная недоступность для каждого клиента.

Что затрагивает operationally

Даже если existing VM продолжает работать, проблема management plane может помешать:

• автоматическому provisioning;
• disaster recovery;
• добавлению IP для нового сервиса;
• IaC pipeline;
• масштабированию;
• срочному созданию replacement resources.

То есть control plane outage — отдельный recovery risk.

Object Storage management 23 августа

23 августа в 12:47 UTC IONOS сообщил, что buckets и Object Storage Keys не отображаются в Data Center Designer. Через DCD было невозможно:

• получить доступ к buckets и keys;
• изменить их;
• создать новые;
• удалить существующие.

Статус переведён в Resolved в 17:48 UTC. Окно записи составило 5 часов 1 минуту.

Формулировка провайдера относилась к Data Center Designer. Поэтому по одной status-записи нельзя утверждать, что весь S3 data plane или чтение уже сохранённых объектов были недоступны. Для мониторинга это нужно разделять:

S3 data plane
  ↓
PUT / GET / LIST объектов через endpoint

management plane
  ↓
создание bucket, keys, policy и управление через DCD/API

Полезно иметь отдельный synthetic check на реальный S3 endpoint и отдельно проверять операции управления.

AI Model Hub и provisioning 13–14 августа

Деградация AI Model Hub продолжалась с 13 августа до утра 14 августа по UTC. Провайдер сообщал о повышенном уровне ошибок и увеличенной задержке.

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

14 августа отдельно возникала ошибка provisioning с кодом VDC-14-1836. IONOS сообщил об установке hotfix. Её нельзя автоматически считать продолжением AI Model Hub incident: затронуты разные компоненты.

Для приложения, использующего AI Model Hub, полезны:

• request timeout;
• retry с exponential backoff;
• circuit breaker;
• резервная model/provider strategy;
• отдельный monitoring error rate и latency.

Managed Kubernetes 4–10 августа

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

В процессе восстановления:

• увеличивались memory limits;
• расширялась инфраструктура;
• customer control planes перераспределялись;
• выполнялась migration на улучшенную infrastructure.

IONOS отдельно указывал, что brief control-plane interruptions не должны были останавливать уже работающие workloads.

Это важно: приложение могло обслуживать traffic, но kubectl, API и cluster management — не работать.

Provisioning 11–12 августа

Проблема относилась к management layer:

• DCD мог терять соединение;
• provisioning выполнялся дольше;
• Cloud API периодически возвращал HTTP 500;
• Terraform, SDK и ionosctl, зависящие от API, также могли получать ошибки.

Провайдер сообщил, что доступность уже созданных virtual data center resources не пострадала.

Ограничения ёмкости — не обычный простой

GPU и MongoDB могли быть частично недоступны не потому, что все existing resources остановились, а потому что отсутствовала свободная capacity для новых instances.

Это создаёт отдельный risk recovery:

resource works now
      ↓
resource stopped/deleted
      ↓
capacity unavailable
      ↓
resource cannot be recreated/restarted

Для GPU IONOS рекомендовал не выключать работающий server во время ограничения. По обновлению общей панели от 21 сентября, 08:31 UTC дополнительная ёмкость введена, ограничение закрыто. Это не гарантия свободного GPU любой конфигурации в будущем и не результат нашего теста. Отдельное ограничение MongoDB de/fra/2 этим сообщением не закрывается.

DBaaS migrations не считать авариями

Августовские PostgreSQL/MariaDB/In-Memory DB migration/deprecation мероприятия описаны отдельно вместе с отключением PostgreSQL API v1 28 сентября и новыми октябрьскими ограничениями создания кластеров старых версий:

• IONOS DBaaS — миграции API и дедлайны версий

Пока planned migration проходит в заявленном impact window, её не следует добавлять в таблицу аварий как incident.

Но missed customer deadline может вызвать outage уже на стороне клиента, например:

• старый MariaDB API v1 integration перестаёт работать;
• приложение продолжает обращаться к отключённому In-Memory DB v1;
• Terraform использует obsolete endpoint;
• PostgreSQL management automation продолжает использовать BASIC auth.

Это operational risk, но не provider incident в том же смысле, что Cloud API outage.

Влияние на категорию

IONOS остаётся в категории «Рискованные». Публикация RCA повышает прозрачность, но временное устранение S3 latency не равно завершению постоянного исправления. Закрытие TXL и GPU capacity 21 сентября учтено отдельно и не стирает историю. Основания категории, связанные с аккаунтом, оплатой и санкционной политикой, сохраняются в карточке провайдера; эти закрытия их не отменяют.

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

• мониторить S3 data plane и Object Storage management plane раздельно;
• для S3 проверять не только availability, но и latency реальных PUT/GET;
• различать период воздействия по RCA, окно публикаций и окончание monitoring;
• IaC pipeline должен иметь retry на временные API errors;
• не считать работающий GPU гарантией возможности повторного запуска;
• перед disaster recovery проверять capacity alternate location;
• AI integration должна иметь timeout/retries/fallback;
• иметь export IaC и план развёртывания у другого provider;
• хранить независимую копию критичных объектов и регулярно делать restore-test;
• подписаться на status notifications;
• scheduled migration deadlines переносить в собственный operational calendar;
• подписывать длительность как окно status-записи, если нет независимого измерения фактического impact.

Связанные материалы

• IONOS provider card
• IONOS DBaaS migrations и дедлайны 2026
• Методика журнала инцидентов

Источники

• Cloud Support: ограничение телефонного канала, 2 октября
• DCD: отдельная карточка события 2 октября
• IONOS Cloud Status: финальные обновления TXL и GPU 21 сентября; закрытие DCD 2 октября
• GPU capacity: карточка события
• TXL: Network Connectivity
• IONOS: S3 latency и RCA от 8 сентября
• Cloud Support: Limited Phone Support Availability
• PostgreSQL API v1 Decommissioning