Debug out loud without guessing wildly

State what you actually know

Start with the observed behavior and the expected behavior. A request timing out is an observation; a database problem is a hypothesis. Keeping those separate prevents your first guess from controlling the investigation.

Ask about the scope: every request or a subset, one region or all regions, a recent release or a longer-running issue. Each answer narrows the search.

Choose a check that distinguishes causes

If both an upstream timeout and a slow query could explain the failure, inspect timing at the boundary between them. Explain what each possible result would mean before proposing the next action.

In a coding exercise, create the smallest input that reproduces the bug. Walk through the relevant state change and test your proposed correction against that input.

Observation, hypothesis, experiment, result. Keep each step visible.

Verify the fix and its neighbors

A passing example is the beginning of verification. Check an empty input, a boundary value, or a repeated request where those cases matter to the bug.

MOG may offer a useful hypothesis during the discussion. Treat it as something to test. Explain the evidence that supports your final answer and the uncertainty that remains.