Heuristic
Start with what changed, not with certainty about it
The last change deserves an interview, not an automatic conviction.
When it fits
- A previously stable system suddenly changes behavior.
When to avoid it
- Failures can emerge without a local deployment when dependencies, data, capacity or external conditions change.
Why it matters
Build a short list of deployments, configuration changes, dependency changes, data-shape shifts and load changes near the onset of the symptom. Compare their timing with the first observable deviation. Use the list to prioritize tests, but require evidence that connects a change to the failure before calling it the cause.
An example
A job starts timing out after a transport import; compare the failure window and behavior before assuming the transport is responsible.
Check your result
At least one recent-change hypothesis becomes stronger or weaker because of a test, not because of chronology alone.
Keep this limit in mind
- Failures can emerge without a local deployment when dependencies, data, capacity or external conditions change.
Connected ideas
Useful withPrefer a test that kills hypotheses
Evidence and sources
Google SRE identifies recent deployments, configuration changes and environmental shifts as productive leads when troubleshooting sudden changes in behavior.
Temporal proximity is a lead, not proof of causation; an unchanged component can still fail because its inputs or dependencies changed.
Effective Troubleshooting · What touched it last