The worst way to read logs during an incident is from top to bottom. That sounds obvious until the room is tense, five terminals are open, and every line looks like it might be the one.
Logs across hosts make this worse. Clocks are a little off. One service logs in UTC, another in local time. One component says "timeout" when it means "caller gave up." Another says "connection reset" because the other side made the only reasonable choice left. If you read everything equally, the loudest service wins.
I usually start by making a narrow timeline. Not a full incident report. Just a strip of time with three or four facts that are hard to argue with: first user-visible error, first alert, deploy or config change, first recovery sign. Then every log line has to earn its place against that strip.
The next step is to find the point of view. A frontend timeout and a database slow query may describe the same event from opposite ends. The useful question is not "which log is true?" They can both be true. The useful question is "where did the delay enter the system?"
For that, correlation IDs help, but they are not magic. They disappear at old boundaries. They get lost in background jobs. They survive in one path and not another. When IDs fail, you go back to rougher tools: timestamps, peer addresses, pid changes, connection counts, queue depth, and the shape of repeated messages.
One habit saves a lot of time: separate cause logs from consequence logs. After a host is unhealthy, every dependent service will start complaining. Most of those complaints are evidence of blast radius, not root cause. They matter, but they do not all deserve equal attention in the first pass.
Another habit is to distrust the first clean story. Incidents love clean stories because humans love clean stories. "The deploy broke it" may be true. It may also be that the deploy increased latency by 5 percent and exposed a disk issue that had been waiting for traffic. The logs will usually tell you if you keep the timeline honest.
The goal is not to read every line. The goal is to reduce panic into a small number of testable claims. This host stopped accepting work before that queue grew. This retry storm started after the first timeout, not before it. This recovery log is late because the service was alive but not useful.
Once the claims are clear, the incident becomes smaller. Not easy, necessarily. But smaller. And smaller is the first thing you need when production is loud.