How to Remove Secrets From Logs Before Sharing

Read the checklist

1. Scan for credentials first. API keys, bearer tokens, JWTs, database connection strings, and private key blocks are the highest-risk items - a leaked key can be used immediately, unlike most other log data.
2. Check for customer and personal data. Emails, phone numbers, payment fields, and identity numbers (SSN, and region-specific formats) should never travel outside your organization's approved tools.
3. Look at field names, not just values. Structured logs (JSON, key=value, Syslog, CEF/LEEF) often label sensitive values clearly - customer_id, tenant_id, session_id - which makes them easy to catch with field-aware redaction even when the value itself doesn't "look" sensitive.
4. Don't forget infrastructure details. Internal hostnames, Kafka topics, cloud resource ARNs, and cluster/namespace names can reveal your internal architecture to someone who shouldn't see it.
5. Keep what makes the log useful. Timestamps, HTTP methods, status codes, stack traces, and error messages are almost never sensitive on their own and are exactly what a human (or an AI assistant) needs to help you debug - don't strip these.
6. Add your own patterns. No automated tool knows your internal project codenames, employee names, or workspace IDs out of the box - add them as custom rules once and reuse them every time.
7. Review before you paste. Skim the cleaned output (or the mapping table) one more time before sharing - especially for a strict/high-stakes destination like a public issue tracker.
8. Rotate real secrets regardless. If a genuine key, password, or cookie appears anywhere in your history for that log - sanitized or not - treat it as exposed and rotate it in the actual system.

What the sanitizer can hide

The built-in cleaner is designed for real logs, stack traces, copied request context, and support snippets that often include accidental share-risk details.

Use cases