A specification describes how a system is meant to be used. An error log describes how it is actually used, including every case nobody wrote down. We started reading logs the way we read requirements documents, and it changed what we build next.
The gap between spec and reality
Specifications describe intended paths. Error logs record every deviation from them: the malformed input a client library sent, the request that arrived twice because a user double-tapped a slow button, the account state that the spec assumed could not exist and does, at low but nonzero frequency, in production.
What a recurring error is actually telling you
A single error is noise. The same error recurring at a steady rate, week after week, across different users, is a design gap wearing a stack trace. It means a real workflow exists that the specification did not anticipate, and users are hitting it reliably enough to be statistically visible.
Where this has changed a roadmap
- A validation error on a date field, recurring at a low steady rate, turned out to be users in a timezone the original design had not considered, entering dates that were valid locally and invalid by the server's assumptions.
- A repeated null-reference error on an account field pointed at users who had signed up through a partner integration that skipped a step the main signup flow always completed.
- A spike in timeout errors at a specific hour, every day, was a batch job elsewhere in the client's infrastructure competing for the same database connections — nothing to do with our code, found only because the pattern was regular enough to be worth asking about.
None of these were reported by a user. All of them were sitting in the logs, visible to anyone who looked at the error rate by type rather than only at the total count.
A support ticket is a user telling you something is wrong. An error log is the system telling you the same thing, for every user who did not bother to write in.
Why totals hide the useful part
Watching a single "error rate" number tells you whether things are generally fine. It does not tell you that one specific error type, small as a fraction of the whole, is the same error recurring for the same reason every time. We now review errors grouped by type and by whether they recur across sessions, not by volume alone, specifically to surface the boring, steady ones that a spike-based alert would never flag.
What this costs
Someone has to actually read the categorised list on a regular cadence, treating it as a genuine source of requirements rather than a firefighting queue. It is unglamorous work. It has found more real product gaps for us this year than any user interview.