What do you log before changing retry code for a 429?

A debugging question about preserving rate-limit headers, bucket identity, shared credentials, and retry timing before changing code.

When an API returns 429, I try to log the endpoint, actor, retry-after, reset time, remaining quota, and whether several workers share one credential before touching retry code. Otherwise it is hard to know whether the fix is backoff, caching, lower concurrency, or a quota request. What do you require in a 429 bug note?