OVHcloud Outage History

The OVHcloud BYOIP incident disrupted the ability to order new BYOIP prefixes via API and the OVHcloud Manager. The issue affected the VIN / Network Services and LIM / Bare Metal Services components, preventing new BYOIP prefix provisioning for several hours. The outage began on 5:05 AM UTC with the incident in maintenance and progressed to staged recoveries, with VIN / Network Services returning to up by 11:04 AM UTC and LIM / Bare Metal Services returning to up by 6:14 PM UTC. The incident lasted roughly 13 hours before full restoration.

OVHcloud reported degraded Bare Metal Services across 13 locations as delays in delivering new dedicated server orders affected provisioning. The impacted components include YNM, YYZ, GRA, HIL, LIM, RBX, SBG, SGP, SYD, VIN, WAW, BHS, and ERI, with widespread impact on deployment timelines across data centers worldwide.

The incident began on Jan 26, 2026 7:09 PM UTC and was resolved by Jan 27, 2026 3:39 PM UTC, lasting approximately 20 hours and 30 minutes. OVHcloud issued four status updates during the incident. A maintenance action affected VIN / Network Services at 5:04 AM UTC, with VIN restored by 11:04 AM UTC and all Bare Metal Services fully restored by 3:39 PM UTC.

The BYOIP incident at OVHcloud prompted a maintenance window affecting a broad set of services and regions. During the window, customers could not order new BYOIP prefixes, though OVHcloud indicated that IP prefixes might be released via API and the Manager. The root cause was identified and a fix was being prepared. The incident began at Jan 26, 2026 9:04 AM UTC and impacted numerous components across network, virtual private, public and private cloud offerings.

OVHcloud issued two status updates during the incident. The outage lasted about 2 hours and was resolved by Jan 26, 2026 11:04 AM UTC as maintenance completed and services returned to normal. Ordering BYOIP prefixes remained unavailable until further notice, with the release of IP prefixes possible through API and the Manager as a remediation option.

OVHcloud experienced a partial outage where new vRack private network orders were not appearing in the Control Panel or via APIv6. Although orders could be placed, the resulting vRack entries were not visible to users, impacting visibility for Bare Metal services HIL, VIN, and GRA. The incident began on Jan 20, 2026 11:14 PM UTC and was resolved by Jan 21, 2026 6:19 PM UTC, lasting about 19 hours. The provider issued 4 status updates during the incident. A fix was deployed at 6:04 AM UTC and, with monitoring, visibility returned to normal for the affected components by 6:19 PM UTC.

The scheduled backbone maintenance window ran from 9:00 AM UTC to 11:00 AM UTC, lasting about 2 hours. The maintenance affected a broad set of OVHcloud backbone components across Bare Metal, Private Cloud, Public Cloud, Network Services and Identity/Security offerings, with OVHcloud reporting no customer-visible service impact during the window.

The incident included 2 official status updates, and maintenance was completed with affected components restored by Jan 19, 2026 11:04 AM UTC. No user reports were recorded during the window.

During a scheduled network maintenance at OVHcloud's Mumbai data center, public and vRack connectivity to servers was temporarily unavailable. The affected racks were YNM0102F03C and YNM0102F04C, impacting Bare Metal Services and Network Services. The outage began at 7:34 PM UTC and ended at 9:34 PM UTC, lasting about 2 hours.

OVHcloud conducted scheduled maintenance on Identity, Security & Operations affecting Public Cloud Services and related Virtual Private Services across regions in the US and Europe. The maintenance window ran from 7:04 PM UTC to 8:29 PM UTC. During this period, customers may have experienced increased latency in Public Cloud products for up to 5 minutes while the work was underway. The incident did not indicate a full service outage, and components returned to normal after the maintenance completed.

Status updates on OVHcloud's status page showed multiple components transitioning to maintenance and then back to up as services were restored. The maintenance affected a broad set of infrastructure, including numerous regional instances of Public Cloud and Virtual Private Services, reflecting a wide but controlled maintenance window rather than a regional outage. The overall duration was about 1 hour and 25 minutes.

OVHcloud conducted a scheduled rack migration in the GRA data center, which led to temporary unavailability of services during the maintenance window. The window was scheduled from 6:00 AM UTC to 11:00 AM UTC as part of ongoing improvements to stability and long-term performance. During this time, many OVHcloud services across Bare Metal, Private Cloud, Virtual Private, Network, and Public Cloud were affected.

OVHcloud experienced a significant outage that disrupted Private Cloud ordering and related management tools across multiple regions. The incident began during a vRops upgrade maintenance window and escalated to affect the OVHcloud US Control Panel and US Website Services. Users reported errors when cancelling commitments in the US portal around 2026-01-07, and on 2026-01-08T18:54:00Z the ability to process new Private Cloud orders degraded across numerous data centers and remained unavailable until 2026-01-10T11:04:00Z. The outage impacted dozens of components across Private Cloud, Network, and related services, with degraded performance and errors during the period. The OVHcloud System Status Page issued eight official updates as the situation evolved, reflecting the progression from maintenance to degraded ordering and back to normal once recovery was complete.

OVHcloud conducted scheduled maintenance on LIM Bare Metal Services, impacting servers in racks L122B01 through L122B05 and causing a loss of network connectivity for about 1 hour. The outage began at 5:04 AM UTC and service was restored by 11:14 AM UTC.

The OVHcloud status page communicated the maintenance window and later confirmed the restoration of service. The impact was limited to the specified racks and did not indicate a broader disruption.