An error log is often copied into a support ticket, monitoring service, or chat. If it contains an authorization header or listener token, the secret has already moved far beyond its original request.
Useful logs do not need every byte of an HTTP exchange. Start with a small set of fields that answer operational questions without revealing private content.
Log the request shape
Record a safe request ID, endpoint category, status code, duration, environment, and a non-secret error category. For a search failure, the full query may not be needed. For a listener operation, an internal diagnostic reference may be enough instead of an email address.
Redact before data leaves the service. Removing a header from the final dashboard does not help if the raw event has already been stored elsewhere. Apply the rule to automatic HTTP-client logging, exception serializers, and retry warnings as well as handwritten messages.
Keep response bodies out of general logs unless a reviewed allowlist permits specific fields. A friendly server error can still contain information that belongs only to one caller.
Test your logging failure paths
Send an invalid credential, trigger a controlled timeout, and return a malformed test response. Search the captured logs for the exact dummy key and token values. They should be absent.
Repeat with a request that fails before reaching your normal response handler. Those early exceptions are common places for a library to print a complete request object.
Choose a retention policy that matches the debugging purpose. A detailed temporary trace for a controlled test does not need the same lifetime as an aggregate error counter. Small, intentional logs are easier to trust and easier to use during an incident.