A record of the times it nearly went wrong
How thin
was the margin?
Twenty-six moments when nuclear weapons, the systems built to control them, or the people reading the screens came close to producing a catastrophe. Each one is scored on a transparent 0–100 index built from five published components, so you can see what almost happened, what stopped it, and how much of that was luck.
- Events documented
- —
- Highest index
- —
- Extreme (86+)
- —
Eighty years of near misses
Almost Doomsday Index
editorial score, 0–100Event ledger
How the index is built
| Component | Weight | Question |
|---|---|---|
| Weapon readiness | 25 | Was a live weapon, warhead or launch capability directly involved? |
| Decision proximity | 25 | How many human or technical steps remained before use or detonation? |
| Information failure | 20 | Did sensors, alarms or communications produce a false picture? |
| Escalation context | 20 | Did a crisis, war or exercise raise the odds of escalation? |
| Recovery fragility | 10 | Did one person, device or coincidence stop it? |
This is not a probability. The Almost Doomsday Index is a curated editorial score, not a scientific estimate. It rates single incidents against each other on five published components, and nothing more. Where you disagree with a number, the component breakdown on each event page shows exactly which judgement to argue with.
The weighting has a known bias. Because escalation context and information failure together carry 40 points, a peacetime weapons accident cannot score as high as a crisis incident — even one, like Goldsboro, that came down to a single switch. That is a deliberate choice: the index measures how close the system came to nuclear war, not only how close one weapon came to detonating. Read the components, not just the total.
Confidence varies. Some entries rest on declassified documents; others on memoirs recorded decades later. Every event carries a source-quality label and, where historians disagree, a “known uncertainty” note. Where an account is contested, the disagreement is part of the story rather than something to smooth over.
Status: first version. The scores are hand-curated from a single research pass. Five events have fully written stories with a minute-by-minute reconstruction; the rest are shorter working drafts.
About the watch
Two of the three alerts are reconstructions. The Vandenberg test and the Pacific thermal event are not documented incidents. They are typical duty traffic, written to show what an ordinary night at Serpukhov-15 looked like: the satellite sees something, the ground radar agrees, you pass it on. Only the third alert is a real event.
The third one happened. Just after midnight on 26 September 1983 the Oko system reported an American launch, then four more, at its highest confidence rating and with no radar corroboration. Stanislav Petrov, the officer on duty, reported it as a system malfunction. The cause was sunlight reflecting off high-altitude cloud into the satellite sensors.
The escalation sequence is speculative and marked as such. If you report the attack, the site shows you a counterfactual. A single report from Serpukhov-15 would not have launched anything: corroboration and a political decision stood between that console and any release order, and Soviet doctrine did not launch on satellite data alone. The sequence compresses steps that really existed. It is there to make the stake legible, not to claim that is what would have happened.
Petrov said it himself. He did not think he had saved the world, and he resisted being described that way. What the record shows is narrower and more useful: a warning system that was confidently wrong, and a procedure that expected a person to pass that confidence upward.
Sources
Support
AlmostDoomsday.com is an independent project with no institution behind it. The domain and the server cost money every month, and that comes out of my own pocket.
Most of the work here is not code. It is reading declassified documents, tracking down which account a claim actually rests on, and deciding what a source does and does not support. That is the part that takes time, and time is what support buys.
Support for an independent project. Not a purchase, no goods or services are provided in return, and it is not tax-deductible. The list on the right is the order I intend to build in as support makes the time available — not a delivery promise.
Roadmap