The running diary the software writes as it works, recording what happened. Debugging is largely reading it.
Why it exists
When something goes wrong in production you cannot step through it live; you need a record of what the system was doing, or debugging is guesswork. Logs exist as the timestamped trail of events a system writes, so engineers can reconstruct what happened and find the cause after the fact.
How it actually works
As the product runs, it writes lines recording events: this request came in, this succeeded, this threw an error. These logs are the primary record of what actually happened, especially when something went wrong.
When a bug is reported, engineers search the logs to reconstruct the sequence that led to it. Good logging is what makes problems findable; missing logs make them nearly invisible.
A senior PM walks you through it
A junior PM, stuck
Support escalated a customer who swears they paid for a Kacchi Biryani, but there is no order under their account anywhere. I asked Rafi and he pasted twelve raw log lines into the thread with just "see anything?". I have stared at them for ten minutes and I honestly cannot tell what I am supposed to see.
Rafi is not testing you, he is handing you the evidence: those lines are the checkout service's own record of Friday lunch, and the answer to your ticket is in them. Each line has only four parts, a timestamp, a seriousness level, which service is talking, and what happened, so you can learn to read this in five minutes. Here is his paste exactly as he sent it, nothing trimmed. Run your eye down the timestamps on the left once, then take the steps with me.
Rafi's paste: checkout service log, Friday 12:58 to 13:07
2026-03-06T12:58:03ZINFOcheckout POST /api/orders received user=u_88452 item=p_1042
2026-03-06T12:58:03ZINFOcheckout stock check ok user=u_88452 item=p_1042
2026-03-06T13:06:41ZINFOcheckout POST /api/orders received user=u_88617 item=p_1042
2026-03-06T13:06:41ZINFOcheckout stock check ok user=u_88617 item=p_1042
2026-03-06T13:06:52ZERRORcheckout POST /api/orders 500 user=u_88617
2026-03-06T13:06:55ZINFOcheckout POST /api/orders received user=u_88397 item=p_1049
2026-03-06T13:07:03ZERRORcheckout POST /api/orders 500 user=u_88397
2026-03-06T13:07:04ZERRORcheckout POST /api/orders 500 user=u_88104
Click a step to see the lines it points at.
Mistakes I've seen
Promising the customer a refund before anyone reads the trace. This log shows no charge was ever attempted, so the honest reply is completely different, and refunding money that never moved creates a second mess.
Bouncing the paste back with "can you just summarize?". You become a relay between support and engineering, every follow-up adds a round trip, and you can never check a claim yourself.
Reading only the ERROR lines. The 500 says the order died, the INFO lines above it say how far it got, and the gap where the payment call should be says what it died before doing.
Treating a missing line as proof by itself. A line can be absent because the event never happened or because nobody logs that event, and only a healthy trace like the 12:58 order settles which one you are looking at.
Filing the follow-up ticket without timestamps or ids. "Checkout was broken at lunch" makes the engineer search from scratch, while "13:06:41, u_88617, POST /api/orders, 500" finds these exact lines in seconds.
Reply in the thread with: "Found it. u_88617 passes the stock check at 13:06:41 but the gateway call never appears, then a 500 at 13:06:52. The 12:58 order shows both payment lines, so this broke with v2.4.1, and this attempt never charged the customer." You pulled one user's thread out of the noise and used a missing line as evidence. That is most of what reading logs is.
Where a PM meets this
"Do we log that?" matters, if an event isn't logged, investigating problems around it is much harder.
Logs can contain sensitive data; what's logged is also a privacy consideration (don't log passwords or full card numbers).
Hear it in a meeting
"The logs show the request never reached the payment service."