The outage started at 2:03 and the on-call engineer did what anyone would do: opened the logs. For the next hour she grepped the application log, filtered by request id, widened the time window, narrowed it again, and found nothing that explained why checkout was timing out. The application log was clean because the application was fine. The failure was in a downstream payment service that logged nothing at all, ran in an account she could not see, and had been quietly rate-limiting the checkout calls for twenty minutes. She searched the application log for an hour not because the answer was there, but because the application log was the thing she could search. The keys were across the street, in the dark.

That is the streetlight effect, and once you have a name for it you start seeing it everywhere: in incident reviews, in dashboards, in research papers, in the way you search your own notes. It is one of the most human biases there is, and it is especially dangerous for people who build with data, because our tools are very good at producing a bright, convenient pool of light and saying nothing at all about the darkness around it.

What is the streetlight effect?

The streetlight effect is a type of observational bias where people look for something only where it is easiest to look, rather than where it is most likely to be. It is also called the drunkard's search, after the parable that gives it its name: a police officer finds a drunk man on his hands and knees under a streetlight, searching for his keys. The officer asks where he dropped them. "Over there, in the park," the man says, pointing into the dark. So why are you looking here? "Because this is where the light is."

The joke is old, but the term was popularized by the journalist David H. Freedman in a 2010 Discover Magazine piece about why so many scientific studies turn out wrong, and the parable itself was used by the philosopher Abraham Kaplan to describe how researchers pick problems. The modern definition on Wikipedia keeps both halves: it is a bias of observation, where you only gather the evidence that is convenient to gather, and a bias of conclusion, where you then act as though the convenient evidence were the whole picture. The first half is understandable. The second half is where the damage lives.

What makes it slippery is that searching under the light is not stupid. The light is where searching is possible at all. The engineer grepping the application log was not being lazy; she was using the one instrument she had. The streetlight effect is not a failure of effort or intelligence. It is a failure to notice that the place you can search and the place the answer lives are two different places, and that the gap between them is exactly where the problem is hiding.

Diagram: a streetlight lights a box of easy-to-search data on the left while the real answer, the keys, sits in the dark on the right.

Why we search under the light

Three forces push us under the lamppost, and they are all reasonable on their own.

The first is availability. Some data simply exists and some does not. You have application logs, so you search application logs. You have a quarter of sales figures, so you reason from sales figures. The data that was never collected cannot be queried, so it quietly drops out of the analysis, not because anyone decided it was unimportant but because it was never on the table to begin with.

The second is cost. Even when the right data is theoretically reachable, getting it is expensive: you would have to add logging to a service, run a longer study, interview the customers who already left, or instrument a part of the system nobody owns. The convenient data is free and immediate. Under deadline pressure, free and immediate beats correct and slow almost every time.

The third is comfort. The lit area is familiar. You know how to read the application log; you do not know how to get into the payment service's account. People gravitate to the methods and the datasets they already understand, and a problem framed in familiar terms feels more tractable even when the framing is wrong. This is the same pull that keeps teams reasoning only to the first visible consequence instead of the harder second and third ones: the near, bright, obvious answer crowds out the far, dark, real one.

None of these is a character flaw. They are the ordinary physics of attention under constraints. But stack them together and you get a team that spends its energy polishing the answer to a question it can see, while the question that actually matters sits unexamined in the dark. If you want to stop doing that, the first move is to notice when it is happening, and the honest way to notice is to write down what you looked at and what you did not. Try Scribelet free and keep that second list, the one nobody usually writes, next to the evidence you actually gathered.

The streetlight effect in software and knowledge work

Modern technical work is unusually prone to the streetlight effect, because our tools manufacture bright, cheap, highly searchable pools of data and stay silent about everything outside them. Here is where the light usually falls, what sits in the dark next to it, and how the failure tends to arrive.

Where the light is (easy to search)	Where the keys are (where the answer lives)	How it bites you
The service that has good logging	The service that logs nothing	You debug the healthy system for an hour while the broken one stays invisible
The metric your dashboard already tracks	The outcome nobody instrumented	The chart stays green while the real thing fails
The benchmark that is cheap to run	The capability that is expensive to evaluate	The model tops the leaderboard and disappoints in production
The users who answer surveys	The users who already left without a word	You optimize for the people you can hear and lose the ones you cannot
The code you wrote recently	The code you inherited and never read	The bug lives in the module you keep not opening
The notes you can keyword-search	The context you never wrote down	You conclude the answer is not in your notes when it was never captured

The through-line is the same in every row: the lit column is a faithful record of what was convenient to collect, and the dark column is where the thing you actually need is sitting. The AI-evaluation row is worth dwelling on, because it is the streetlight effect operating at the frontier of the field. Benchmark scores are easy to compute and easy to compare, so they become the light, and enormous effort flows toward raising them. Whether the model is actually good at the messy, open-ended task you care about is expensive to measure, so it stays in the dark, and a whole industry periodically rediscovers that the leaderboard and the usefulness were two different places all along.

Streetlight effect vs Goodhart's law vs the McNamara fallacy

The streetlight effect travels with a family of measurement failures, and they get blurred together constantly, which is a shame because each one names a genuinely different mistake. Keeping them straight makes all of them sharper.

	What goes wrong	The core move
Streetlight effect	You search where it is easy to look, not where the answer is	Convenient evidence stands in for the real evidence
Goodhart's law	A good measure stops being good once it becomes a target	A metric gets gamed and decouples from the goal
The McNamara fallacy	You treat what you did not measure as if it did not exist	The unmeasured is deleted from the decision
Campbell's law	High stakes corrupt both the metric and the work beneath it	Pressure bends the process out of true
Simpson's paradox	An aggregate reverses the trend inside its own segments	The summary number lies about the groups

The distinctions are subtle but real. Goodhart's law and Campbell's law are about a metric going bad under pressure: someone sees the target and games it. The streetlight effect needs no pressure and no gaming. It happens at the very start, when you decide, usually without noticing you are deciding, which evidence to go looking for. The McNamara fallacy is its closest cousin, and the difference is one of direction. McNamara is about ignoring the data you did not gather; the streetlight effect is about where you chose to search in the first place. You can commit the streetlight effect and the McNamara fallacy in a single motion: you search under the light, find a number, and then treat that number as the whole of reality. The streetlight effect is how the blind spot forms; the McNamara fallacy is what you do once you are standing in it.

How to catch yourself under the lamppost

You cannot abolish the streetlight effect, because you will always have more light in some places than others. What you can do is build the habit of asking, before you trust a search, whether the light and the keys are actually in the same place. A few questions do most of the work.

Ask before you trust the search	Healthy answer	Streetlight answer
Where did I actually look?	I can name the dataset and its edges	Wherever the query was easy
Where is the thing most likely to be?	I thought about it independently of where I can see	I assumed it was where I was looking
What did I not search, and why?	Because it was costly, and I noted that	I did not think about what I skipped
Is my conclusion about reality, or about my data?	About reality, checked against the data's limits	The data said so, so it is true
What would change my mind?	Evidence I would have to go into the dark to get	Nothing I can reach from here

The single most useful move on that list is the third one: name what you did not search. A factor you have written down as "not checked, would need logging in the payment service" stays visible as a known gap. A factor nobody wrote down disappears, and three weeks later the team remembers the investigation as thorough when it only ever covered the lit half of the problem. This is the same discipline that keeps the reasoning behind a decision from rotting the moment nobody is actively holding it: the unexamined dark does not announce itself, so you have to record its outline on purpose.

It also helps to treat cost as a signal rather than a verdict. When the right evidence is expensive to get, that expense is often a clue that you are near something important, not a reason to substitute the cheap evidence and move on. The teams that match their method to the actual decision rather than to the data they happen to have are the ones that end up looking in the right place, even when the right place is dark and awkward and slow.

The light you build for yourself

There is a version of the streetlight effect that happens entirely inside your own head, and it is the one most relevant to anyone who keeps notes. When you go looking for something you once knew, you search where searching is easy: the recent notes, the well-tagged ones, the phrases you can remember well enough to match. If nothing turns up, the natural conclusion is that you never wrote it down. But that conclusion commits the streetlight effect twice over. The thing may be there, phrased in words you no longer recall, in a note you cannot surface because your search only reaches the lit corner of your own archive. Or it was genuinely never captured, which means the darkness was there all along and you simply confirmed it.

The fix is to make more of your own knowledge searchable, and to make the dark parts explicit instead of pretending they are empty. When you capture a decision, write down not just what you chose but what you could not check and chose to proceed without. Try Scribelet free and keep the context that usually stays in the dark, the caveats, the paths you did not explore, the evidence that was too expensive to gather, somewhere it will still be legible later. Scribelet's background agents even re-check what you have written against the world over time, so a gap you flagged as "unverified" does not quietly get mistaken for settled fact while you are looking the other way. The point is not to light up everything at once. It is to stop mistaking the edge of your light for the edge of what is real.

Reading the streetlight effect correctly

The overcorrection is to distrust any convenient evidence on principle, which just paralyzes you, because all evidence is convenient from some angle and you have to start somewhere. The lesson is not that the lit area is worthless. The application log was worth reading; it just was not the whole system. The lesson is narrower and more useful: the place you can search and the place the answer lives are not guaranteed to be the same place, and the entire discipline is the habit of checking the gap between them before you act.

So the question the streetlight effect leaves you with is not "do I have enough data?" It is "am I looking here because this is where the answer is, or because this is where the light is?" Ask it out loud in your next incident review, your next metrics meeting, your next search through your own notes. Most of the time the honest answer is some of both, and naming the dark half is what keeps you from walking confidently in the wrong direction. Try Scribelet free and keep a record of where you have actually looked, so the next person, including the future version of you, can tell the lit ground from the ground you never covered.