How One Software Bug Almost Shut Down an Entire Power Grid

In 2015, a single line of code nearly triggered a cascading blackout across parts of Turkey. The bug was simple: a loop that didn’t account for a boundary condition. The consequences could have been enormous. It’s a story that gets almost no attention—and it should.

Software runs the critical infrastructure that keeps lights on, water flowing, and traffic moving. Most of the time, it works. When it fails, the results can be catastrophic. The Turkey incident is a reminder that the systems we take for granted are held together by code written by fallible humans, tested in environments that can’t fully replicate reality, and operated under assumptions that sometimes break.

The Incident

Turkey’s national electricity operator, TEİAŞ, runs a supervisory control and data acquisition (SCADA) system that monitors and controls the grid. In 2015, a software update introduced a bug in the energy management system. The fault caused incorrect calculations of power flow across transmission lines. When the system tried to compensate, it triggered a chain of protective relay trips—circuit breakers that shut down lines when they detect abnormal conditions.

The relays did their job: they protected equipment from overload. But the cascading trips began to isolate parts of the grid. In a matter of minutes, several regions lost power. The blackout was eventually contained, but only after manual intervention and coordination across control centers. Millions of people were affected.

Investigators traced the root cause to a programming error. A loop or calculation failed to handle a specific edge case—possibly a zero division, an array index out of bounds, or a null value where none was expected. The kind of bug that slips through code review and testing because it only manifests under a rare combination of grid conditions.

Why This Happens

Critical infrastructure software is old. A lot of it runs on codebases that date back decades. SCADA systems, industrial control systems, and energy management platforms are built for reliability and longevity—not for rapid iteration. Updating them is risky. Testing them against every possible grid state is practically impossible. The grid is a dynamic system: generation, load, and topology change constantly. Simulating every failure mode is expensive and incomplete.

So bugs slip through. Sometimes they’re logic errors. Sometimes they’re integration issues—new code interacting badly with legacy systems. Sometimes they’re timing or concurrency problems that only appear under load. The software is written by skilled engineers, but the complexity of the domain and the difficulty of full-system testing create gaps.

The Human Factor

Operators in control rooms are the last line of defense. When the software misbehaves, they have to diagnose and respond in real time. During the Turkey incident, operators had to override automated decisions, manually trip or close breakers, and coordinate with neighboring regions to stabilize the grid. Their training and judgment prevented a wider blackout.

But humans make mistakes too. Under stress, with alarms flooding in and minutes mattering, the best-prepared team can misread a situation. The software is supposed to help—to give clear, accurate information and sensible recommendations. When the software is wrong, operators are flying blind.

What We Can Learn

The Turkey case isn’t unique. Similar incidents have occurred elsewhere: software bugs, configuration errors, or human mistakes that cascaded into regional blackouts. The pattern is familiar: a small trigger, a system that overreacts, and infrastructure that wasn’t designed to fail gracefully.

The takeaway isn’t that software is untrustworthy. It’s that critical systems need multiple layers of defense: better testing, redundancy, operator training, and designs that assume failure. The bug that almost shut down Turkey’s grid was preventable. The next one might be too—if we take the lesson seriously.