Four checks before sharing a log

Share the smallest useful excerpt

Troubleshooting often needs only a few lines around the failure. Work on a local copy and remove unrelated requests, user content, and large bodies. Never paste production logs, private keys, or seed phrases into public discussions.

level=error request_id=demo-001
Authorization: "Bearer demo_token_not_real"
email=developer@example.com
path=C:/internal/demo-project
error="upstream timed out"

Review four dimensions

• Credentials: authorization, cookies, API keys, passwords, and connection strings.
• Personal data: email, phone numbers, user content, identity documents, and location.
• Environment details: internal domains, paths, hostnames, tenant IDs, and endpoints.
• Context: whether remaining details still identify a person, customer, or incident.

PlainKit masks common credentials and emails, with optional IPv4 and EVM address masking. It cannot recognize every path, phone number, or custom field. The internal path in this example needs manual review.

If a secret leaks, deletion is not enough

If a real credential was shared, revoke or rotate it through its service and review access records. Deleting a public message may leave caches or copies. Search the redacted output for known sensitive values and have an authorized person review the scope.