Logs you can still debug at 2 a.m.

A request id, a model name, a token count, and a reason for the retry will save you more time than another dashboard.

The worst outage I had this year was not a GPU failure. It was a retry loop that looked like success if you only watched HTTP 200s. The client kept asking, the server kept answering with a truncated stream, and the dashboards stayed green because each fragment was technically fine.

What I want in a single log line now: a request id that follows the call from gateway to worker, the model and revision, input and output tokens, first-token latency, end-to-end latency, and why a retry happened if it did. I also want the abort reason, not just “cancelled.”

Pretty charts are for the next morning. At 2 a.m. you need to grep one id and see a story. If your tracing system cannot do that, you do not have tracing, you have decoration.