Summary
- IONOS reported sporadic connectivity problems and substantial packet-delivery delays in its TXL region.
- Provisioning delays were also reported while engineers worked on the network problem.
- The incident ran from 08:43 UTC until IONOS marked it resolved at 14:33 UTC.
IONOS Cloud has resolved a network incident in its Berlin TXL location that caused sporadic connectivity problems, substantial packet-delivery delays, and delays in provisioning cloud resources.
The provider first reported the problem at 08:43 UTC on 24 September and said its network technicians had begun work immediately after detection.
IONOS warned that individual virtual resources could experience degraded connection quality while the investigation continued. At 08:58 UTC it added that customers could also see delays when provisioning resources.
A fix was implemented by 11:57 UTC and moved into monitoring. IONOS marked the incident resolved at 14:33 UTC, around six hours after the first status notice.
The company has not published a root cause for the incident, so the available status record does not establish whether the problem originated in routing, switching, transport, power, software, or another part of the TXL infrastructure.
That distinction is important. Packet loss and slow provisioning can be visible to customers at the same time while arising from different dependencies, and the status update alone is not sufficient to determine whether the provisioning delay was directly caused by the network fault or simply occurred alongside it.
IONOS’s TXL location provides compute, storage, network, Kubernetes, provisioning, object-storage, and private-cloud services. The company’s status page showed those components as operational after the incident was resolved.
The TXL environment has experienced separate network-connectivity problems earlier in September, including an incident associated with a router replacement. The 24 September notice does not link the new disruption to that earlier event and should be treated as a separate incident unless IONOS provides further information.
Operational status pages rarely provide the depth of a formal post-incident report, but they are useful in showing how facility and network reliability translates into customer-facing cloud performance. In this case, the immediate impact was not a declared regional outage but degraded connectivity and provisioning — precisely the type of partial failure that can be harder for customers to isolate than a clean loss of service.
IONOS had not disclosed a root-cause analysis for the 24 September incident at the time of drafting.
