Summary

  • The French state accident investigation (BEA-RI, report MTE-BEARI-2022-005, published 24 May 2022) places the fire's origin in SBG2's ground-floor energy rooms, which housed batteries and uninterruptible power supplies, were fitted with fire detection, and had no automatic extinguishing system. It records ignitions almost simultaneously on batteries and on an inverter.
  • OVHcloud's own first-day account puts the outbreak at 00:47 and describes an immediate, protocol-driven response; the official chronology begins at 00:35. The two timelines differ by about twelve minutes and have not been reconciled in public. This article presents both rather than merging them.
  • The protection gap is a fact about suppression and electrical isolation, not a cause. The report explicitly declined to establish a cause, which it said remained with judicial experts, and a reported humidity observation near the inverters was never resolved into a finding.
  • The only court-established failure so far concerns the product rather than the fire: France's Commercial Court of Lille Métropole ordered OVHcloud to pay Bati Courtage EUR 100,000 and Bluepad EUR 150,000 because paid backup services kept backups in the same SBG2 building as production. Claims of negligence over fire safety were dismissed.
  • No public evidence located for this article independently verifies that backup locality, suppression or cross-site redundancy changed durably after 2021. OVHcloud's recovery and compensation figures are company-reported, and the durability question stays open.

What burned, and what was measured

Independent internet measurement by Netcraft put roughly 3.6 million websites across about 464,000 distinct domains offline at the peak of the outage, with more than 18 per cent of OVH-attributed IP addresses unresponsive between 06:00 and 07:15 UTC on 10 March 2021 (Netcraft analysis). Contemporaneous wire reporting described government agency portals, banks, shops and news sites among the affected properties, and internet monitors tracking a large slice of the .FR web space going dark (Reuters, 10 March 2021).

The physical damage was concentrated. Building SBG2 was destroyed. Building SBG1 was partially destroyed, losing four of its twelve rooms, and the inter-building link to SBG3 was affected (BEA-RI investigation report). Nobody was killed or injured (BEA-RI investigation report).

OVHcloud's own same-day statement recorded that the site is not classified as a Seveso installation, that firefighters isolated the site and its perimeter from 02:54, that by 04:09 SBG2 had been destroyed while the fire still threatened neighbouring data centres, and that from 05:30 the site was inaccessible to OVHcloud's own teams under the direction of the prefecture (OVHcloud community statement, 10 March 2021). The company said at the outset that it would communicate transparently on causes and impacts and pointed customers to its status page (OVHcloud community statement). Trade coverage that day recorded the same sequence of destruction and isolation (Data Center Knowledge; Cloud Computing News).

The mechanism the investigation did describe

The Bureau d'enquêtes et d'analyses sur les risques industriels (BEA-RI), the industrial accident investigation body inside France's Ministry of the Ecological Transition, published its report on 24 May 2022. Its account of the origin is specific:

L'incendie a pris naissance au sein des locaux qui abritent les batteries et les ASI ... Ces salles ... étaient équipées d'une détection incendie mais ne disposaient d'aucun système d'extinction automatique. Les départs de feu se sont produits quasi-simultanément sur des batteries et sur un onduleur.

In English: the fire began inside the rooms housing the batteries and the uninterruptible power supplies needed to run the servers; those rooms were equipped with fire detection but had no automatic extinguishing system; the ignitions occurred almost simultaneously on batteries and on an inverter (BEA-RI investigation report; mirrored copy of the report). The same report documents the response sequence: first alarm at 00:35, a guard seeing thick black smoke in energy room 2 of SBG2 at 00:37, evacuation at 00:39, the fire service called at 00:42, first responders on site at 00:59, emergency power cut to SBG2 at 01:13, power cut to SBG1, SBG3 and SBG4 at 01:28, the fire extinguished at 10:02, and the intervention ending at 18:13, after roughly 4,000 litres of foam had been used (BEA-RI investigation report).

Two structural features of that sequence matter for anyone who buys availability. First, the rooms that ignited had detection without automatic suppression, so the first defence was human and depended on how fast the fire service could work. Second, the neighbouring buildings' power could only be cut after the fire was already established, meaning the campus-level response and the customer-visible outage were bound together by the electrical topology. The report drew safety lessons on automatic extinguishing systems, battery maintenance, building design and emergency planning, including electrical shutdown (BEA-RI investigation report; trade reporting on the report's findings).

Two timelines, one unresolved cause

OVHcloud's corporate newsroom page states that the fire broke out on 10 March at 00:47, that its detection systems activated instantly, that its teams responded according to the protocol in place for the energy rooms where smoke was detected, and that firefighting operations could only be carried out after electrical power was switched off for the entire site, including all four data centres (OVHcloud Strasbourg update). Its first-day community statement used the same 00:47 timestamp (OVHcloud community statement).

The official chronology starts at 00:35 and cites a fire-service call at 00:42 (BEA-RI investigation report). Read together, the two accounts differ by about twelve minutes at the very start of the event, the period in which detection, verification and escalation decide how much of a fire is left to fight. Nothing located for this article reconciles them, and readers should treat both as party and investigator accounts respectively rather than as one agreed record. OVHcloud noted that authorities and insurers were still investigating the timeline, the outbreak and the spread of the fire to identify its cause (OVHcloud Strasbourg update).

On cause, the official position is deliberately incomplete. The BEA-RI report did not establish a definitive cause and said the question remained subject to judicial expert assessment (BEA-RI investigation report). Trade reporting on the investigation recorded a finding that water or humidity had been detected near the power inverters before the fire, while the report itself did not resolve whether that humidity reading was a measurement error (Data Center Dynamics on the report). That is a reported observation about conditions, not an established ignition cause, and it should not be read as one.

The contractual failure the courts did find

While the cause stayed open, a narrower question reached court and produced findings. France's Commercial Court of Lille Métropole ordered OVHcloud to pay Bati Courtage EUR 100,000 in a decision of 3 February 2023 and Bluepad EUR 150,000 in a decision of 16 March 2023 — EUR 250,000 in total — because the paid backup services those customers bought kept their backups in the same SBG2 building as their production data, so both copies were destroyed in the same fire. The court found that the promised backup service had not been delivered, while dismissing negligence claims concerning fire safety (Data Center Dynamics on the rulings; Blocks & Files on the rulings).

The distinction is the whole story. The court did not hold that OVHcloud started the fire or that its fire prevention was negligent; on the reporting available, it declined that line. What it found was a gap between what a paid product promised and where the protected copy physically sat. Trade reporting indicated OVHcloud intended to appeal the Bluepad ruling (Blocks & Files). These are first-instance decisions reported through trade coverage rather than judgments read directly for this article, and any appeal outcome is unresolved until a primary record shows otherwise.

The remedy: announced, and how far verified

OVHcloud announced tiered compensation for affected customers. For destroyed VPS without disaster recovery it offered six months of compensation; where disaster recovery existed it offered a rebuild, or a full refund plus three years of free service if a rebuild was impossible (Techerati on the compensation plan).

It also published recovery figures: an estimated 120,000 services fully or partially affected, of which about 113,000 were fully recovered at the time of the update; 14,472 bare-metal servers delivered as alternative solutions in other data centres; 30,775 VPS restored with roughly 5,900 remaining; billing stopped for affected SBG services; and free-pricing measures for affected customers (OVHcloud Strasbourg update). Those numbers are company-reported and reflect an unspecified update time rather than a final audited count, which is a boundary on how they can be used, not an accusation.

What is missing is the dimension that matters most for availability accountability: independent evidence that the arrangement which failed has been replaced. The named gap is concrete. A published post-incident engineering audit or independent review of the Strasbourg energy rooms and their suppression would test the declared redesign. An appellate or merits ruling on backup architecture would test whether same-site backup is treated as a product defect or an acceptable configuration. Disclosed contract changes on backup locality and off-site replication would test what customers are actually promised now.

Later outage or data-loss disclosures at the same or comparable sites would test whether behaviour changed. Regulator or supervisory findings, and insurance or subrogation outcomes that quantify residual loss, would supply the price of the failure. None of these has been located in the public record for this article.

That is not a claim that nothing was fixed. It is a statement that the fix is currently known to readers mainly through the statements of the party that had to make it, which is the weakest form of assurance available. For an operator whose customers were told their data was protected, the difference between an announced remedy and a verified one is the whole value of the product.

Sources and evidence