The Moth in the Machine Was Not the First Bug

By Ryan Nichols

On September 9, 1947, a team working with Harvard’s Mark II computer found a moth caught between relay contacts.

They removed it.

Then somebody did the part that made the moment last.

They taped the insect into the machine’s logbook.

The page carried a joke: “First actual case of bug being found.”

The machine failed. The team fixed it. The record survived.

That is the story most people know.

The cleaner version is also wrong in two important ways.

The moth did not invent the word

The Computer History Museum’s account says the term “bug” had roots in engineering going back to Thomas Edison in the 1800s. The Mark II team was not naming a new category of failure. The handwritten line was funny because the word already had meaning.

This time the bug was literal.

That distinction matters because good history does not need a false first to stay interesting.

The 1947 incident became one of computing’s most memorable physical artifacts. The Smithsonian’s National Museum of American History preserves the logbook page, moth and all.

It is evidence with a punchline.

Grace Hopper made the story famous, but the logbook was a team record

Grace Hopper was part of the Mark II team and later carried the story into public lectures. The Computer History Museum credits her with making the incident famous.

That does not prove she found the moth or wrote the line.

Popular retellings often compress a team, a machine, and a maintenance record into one heroic moment. The result is easier to remember and harder to verify.

The better version leaves room for what the source actually shows: engineers working on the Mark II documented a physical insect in the relay system, and Hopper later helped the story travel.

The record is strong enough without inventing a signature.

The logbook was part of the work

The most useful object in the story is not only the moth.

It is the logbook.

Complex machines fail in ways that feel obvious after the cause is found. Before that moment, operators have symptoms, guesses, tests, and dead ends.

A maintenance log turns those scattered moments into a sequence:

• what happened
• when it happened
• what the team inspected
• what it found
• what changed after the repair

The moth gave this page personality. The habit of documenting the machine gave the moth somewhere to land.

Every Automation Needs a Failure Receipt applies the same principle to modern systems. A green checkmark is not enough. The record should show what was accepted, what started, what completed, what failed, and who owns the next move.

A physical cause can still hide inside an abstract system

The Mark II was an electromechanical machine. Relays moved. Contacts opened and closed. An insect could physically interrupt the work.

Modern software feels less tangible, but failures still cross boundaries.

A perfect form can fail because the network drops. A correct automation can fail because a vendor rejects one field. A database can receive the record while the notification never leaves. A customer can click submit while the operator sees nothing.

The screen shows the symptom. The cause may live somewhere else.

That is why debugging requires more than staring at the place where the problem became visible.

Follow the sequence. Preserve the input. Check the handoffs. Record the correction.

Do not waste the strange failure

Most failures are not famous.

There is no moth to tape into a book. There is a missing field, a dead battery, a wrong assumption, a timeout, or a promise that did not move to the next person.

The discipline is the same.

When something breaks, capture five lines:

1. What was supposed to happen?
2. What actually happened?
3. What evidence survives?
4. What was changed?
5. How will the next person know whether the repair worked?

Do that before the details flatten into a story about bad luck.

The Night the Telegraph Wires Woke Up tells another story about technology behaving in a way its operators did not expect. The First Electronic Television Image Was One Straight Line shows how a tiny proof can carry a much larger future.

The moth story holds both lessons.

A small physical cause disrupted a large machine.

A small preserved record outlived the machine room.

Keep the receipt

The Mark II team did not know people would still be talking about that maintenance entry seventy-nine years later.

They kept it anyway.

Not every record needs a museum. Every important failure does need enough truth for the next person to understand what happened.

Fix the system.

Write down the cause.

Keep the receipt.

Then read Every Automation Needs a Failure Receipt and build the modern version into the next workflow before another bug arrives.

Source verification: Computer History Museum and Smithsonian collection pages were checked September 9, 2026, at 4:07 a.m. Central.

Editorial visual disclosure: The header image is an original AI-assisted historical concept. It does not reproduce the Smithsonian logbook, a real document, the Harvard Mark II installation, or a real event photograph.