This $500 Million Bug Took Down Ariane 5 in 37 Seconds
In this article
Bottom line: On June 4, 1996, the European Space Agency's Ariane 5 rocket self-destructed 37 seconds after liftoff because a 64-bit floating-point number got stuffed into a 16-bit integer variable that had no business being calculated after launch in the first place.
The code was reused, unchanged, from Ariane 4 — where the same math never overflowed because that rocket flew a slower trajectory.
The failure destroyed four Cluster satellites and wiped out roughly $370 million in hardware in under a minute, on top of a decade and nearly $7 billion in program development. No hardware broke.
The rocket was structurally perfect. A single unguarded conversion killed it.
I've shipped code I was sure couldn't fail because "we tested this exact logic on the last version." Every engineer has.
Ariane 5 is what happens when that instinct meets a rocket, an unchecked exception handler, and 37 seconds.
The Setup: A Decade of Work, Airborne for Under a Minute
Ariane 5 was Europe's answer to a bigger, more expensive future in space — a heavy-lift rocket designed to carry twice the payload of its predecessor, Ariane 4, at a fraction of the relative cost.
The European Space Agency spent roughly ten years and close to $7 billion developing it.
Flight 501 was the maiden launch, carrying four uninsured Cluster satellites built to study how the sun's plasma interacts with Earth's magnetosphere.
At T+0, everything looked normal. The two solid boosters ignited, the main engine lit, and the vehicle climbed cleanly off the pad at Kourou in French Guiana.
Then, at about 37 seconds, the rocket suddenly pitched hard, the aerodynamic forces on the airframe exceeded what it was built to survive, and the vehicle began to break apart.
The automatic self-destruct system did its job and detonated the wreckage over the launch site.
Four satellites, one rocket, gone — and not because of weather, not because of a cracked weld, not because of a manufacturing defect.
Round 1: What the Investigation Actually Found
The inquiry board pulled telemetry and reconstructed the failure in days, which tells you something — this wasn't some exotic, hard-to-diagnose fault.
It was almost embarrassingly simple once you saw it.
Ariane 5's guidance relied on an Inertial Reference System (the SRI) that continuously calculates the rocket's orientation and velocity.
As part of that process, a piece of software converted a 64-bit floating-point value representing horizontal velocity into a 16-bit signed integer.
That conversion function had exactly one job: keep a number that should never realistically exceed roughly 32,767 within a variable that could only hold values up to 32,767.
On Ariane 5, the number blew past it.
The rocket's actual flight path built horizontal velocity much faster than Ariane 4 ever did, because the two vehicles have completely different trajectories in the first seconds of flight.
The value overflowed.
The SRI software had no exception handler wrapping that specific variable — it wasn't defensively coded against a bad input, it was coded on the assumption the bad input could never occur.
It occurred within roughly 36.7 seconds of liftoff.
The Part That Should Make You Uncomfortable
Here's the detail that turns this from "sad accident" into "case study every engineer should know." That conversion function wasn't even needed for Ariane 5's flight.
It was part of an alignment routine designed to run for about 40 seconds after liftoff on Ariane 4 — a holdover from ground procedures where recalculating horizontal bias mattered.
Nobody removed it for Ariane 5. It was reused wholesale, because it had flown successfully dozens of times on Ariane 4 and re-verifying it felt unnecessary.
The engineering team had actually done a rigorous analysis years earlier proving that four of the seven variables in this section of code could never overflow, given Ariane 4's flight profile.
Three others, including the one that killed Flight 501, were left unprotected for performance reasons — Ada exception handling had a computational cost, and the team decided the analysis already proved the risk was zero.
That analysis was never redone for Ariane 5, a rocket with a materially different trajectory.
The code that flew on 501 had literally never been tested under Ariane 5's real flight conditions before the actual launch.
Round 2: Why the Backup System Didn't Save Anything
This is the part that gets glossed over in the quick version of the story, and it's the part that matters most if you build anything with redundancy baked in.
Ariane 5 had two SRI units — a primary and a hot backup, specifically so that if one failed, the other would take over. Standard aerospace practice. Except both units were running identical software.
When the primary overflowed and its exception handler shut it down entirely — because the design philosophy treated any internal software exception as equivalent to a random hardware failure, not a systematic bug — the backup unit hit the exact same overflow on the exact same input, milliseconds later, and shut down too.
Redundancy protects you against a component randomly breaking.
It does nothing against a bug, because a bug isn't random — it's deterministic, and identical hardware running identical software will hit it at the identical moment, every time.
Two computers making the same mistake in lockstep isn't backup. It's just one failure wearing two hats.
When the SRI shut down, instead of going silent, it did something worse: it output diagnostic error data — essentially internal debugging bit patterns — onto the same data bus that normally carried real flight guidance numbers.
The onboard flight computer, which had no way to distinguish "this is diagnostic garbage" from "this is a legitimate steering command," read that garbage as an instruction to swing the rocket's nozzles to their maximum deflection.
The rocket obeyed.
It veered sharply off its flight path, the aerodynamic loads tore at the structure, and the self-destruct sequence triggered automatically, exactly as designed, for exactly the wrong reason.
The Results: A Failure With No Hardware Cause
Every physical system on Ariane 5 Flight 501 worked. The engines, the boosters, the airframe, the sensors — all fine.
The entire loss traces to one unguarded type conversion in reused software, compounded by a redundancy architecture that couldn't actually redound against a software bug.
- Time to failure: ~37 seconds after liftoff
- Root cause: 64-bit float → 16-bit signed integer overflow, unhandled
- Code origin: Reused from Ariane 4 without re-verification for Ariane 5's flight envelope
- Redundancy outcome: Both SRI units failed identically within milliseconds — identical software eliminates the benefit of duplicate hardware
- Direct loss: ~$370 million in vehicle and payload; the broader program had absorbed nearly $7 billion in development to get to this one flight
- Physical hardware failures: Zero
The fix that followed wasn't exotic.
ESA added the missing exception handling, removed the now-pointless post-liftoff alignment code entirely, and — more importantly — overhauled the verification process so that reused modules got re-validated against the actual operating conditions of the new vehicle, not just the one they were proven on.
Ariane 5 flew successfully afterward and became one of the most reliable heavy-lift rockets ever built.
The fix wasn't the hard part. Realizing that "it worked before" isn't a verification strategy was.
What This Means for You
You are not launching rockets, but you are absolutely reusing code with assumptions baked in that nobody re-checked.
Every engineering team has an Ariane 4 module running inside their Ariane 5 — some piece of logic that was proven correct under one set of conditions and quietly carried into a system with different ones.
The lesson isn't "write more exception handlers," though that's part of it.
It's that "this was already tested" is a claim about a specific input range, not a guarantee, and the moment your system's real-world envelope changes, that old proof stops applying.
If you're integrating a third-party library, migrating a service to handle new traffic patterns, or — very relevant right now — shipping AI-generated code that was pattern-matched from a different context, ask the boring question: was this logic actually verified for these conditions, or just conditions that happened to look similar?
That single question would have grounded Ariane 5. It's cheap to ask and expensive to skip.
And on redundancy: if your failover runs the identical code path as your primary, you don't have redundancy against software bugs — you have one failure mode with two triggers.
Real resilience against a software fault requires actual diversity: different logic, different assumptions, or at minimum a sanity check on the input before it ever reaches the part of the system that acts on it.
The Twist
The most unsettling fact in the whole investigation isn't the overflow itself — it's that the function computing the overflowed value had no purpose whatsoever after liftoff on the rocket that flew it.
It kept running out of inertia, not necessity, because removing dead code felt riskier than leaving it alone. Sometimes the most dangerous line in your codebase isn't the one doing something wrong.
It's the one nobody remembers is still doing anything at all.
What's the "it worked on the last version" assumption sitting in your codebase right now that nobody's gone back to re-check?
