Enterprise Drupal / April 2026
In a production incident, the most useful first commit is often the one you do not write
During support work, the fastest route was repeatedly to collect reliable runtime evidence first and modify code only after the failing layer had been narrowed down.
Situation
When something breaks in production, there is immediate pressure for a quick fix. In a familiar stack, three plausible hypotheses appear within minutes and it is easy to patch the first one. The problem is that the same symptom can come from cache, data, configuration, an external service or an actual code defect.
Approach
I began diagnosis with reproducible observation: exact request, timestamp, correlated logs, affected configuration and recent changes. Only then did I promote a hypothesis. When temporary diagnostics were necessary, I used targeted, removable logging rather than enabling broad debug mode in production.
Outcome
Several incidents showed that the obvious first code fix would have landed in the wrong layer. Once the real cause was identified, a smaller and safer change was enough — or no code change was needed at all. The same evidence trail also remained useful for later root-cause analysis.