"Works on my machine" is the punchline of a thousand stickers. I want to argue it's one of the more informative sentences in debugging, as long as you don't stop there.

It's a differential, not an excuse

If something works in one place and fails in another, you have been handed a constrained search space for free. The bug is not in the code — the code is identical. It's in the difference.

That's enormously better than "it's broken." The entire remaining job is enumerating differences and testing them. Tedious, but bounded.

The failure isn't saying the phrase. It's saying it and going for lunch.

The list, roughly in order of how often it's been the answer for me

• Data. Your local database has a row that production doesn't, or the reverse. Fixtures, a seed dump, something you created by hand in March and forgot.
• Scale. Fifty records locally, fifty thousand there. Everything correct, nothing performant, and some things behave differently past a threshold.
• Identity. You're an admin locally. The failing user isn't.
• Time and ordering. Your machine is fast enough that a race never loses.
• Environment. A variable set in your shell two months ago that you now believe is a law of nature.
• Version. Of a dependency, a runtime, an image tag that moved under you.

Data has been the answer more than everything else combined, for me.

The trap I fell into

The nastiest version is when your local reproduction succeeds — you reproduce the bug locally, fix it, and it's still broken in production.

That means you found a bug. Not necessarily the bug. The local repro was a hypothesis you then confirmed, which feels like proof and isn't.

I lost two days to exactly this. The only thing that would have saved me was reading the actual failing run before building the theory, and I didn't, because my theory was good.

The question to hold

Not "why does it fail there?" but "what is true there that isn't true here?"

The second one has a finite answer.