Log File Sanitisation
Clean logs before sharing with support teams or vendors
Outcome
Prepare logs for support, vendors, or public issue trackers while preserving useful debugging context and removing sensitive values.
Your progress
Mark each step as you complete it. This is saved only in this browser.
0 / 3 steps complete
Before you start
Visual frame
Review asset
Log file sanitisation storyboard
Synthetic log frame only. It uses fake stack and request values and avoids asking users to send raw logs to support.
Synthetic frame
Log scope
Reduce noise before review.
Log sharing frame
A debugging-first flow that narrows the log, sanitises sensitive fields, and keeps useful context intact.
Guided steps
Follow the task, then check the result.
Choose the smallest useful log scope
Start with the smallest time window or request sequence that still shows the issue. Less log data means less private context to review.
Review secrets and identifiers in context
Check for emails, user IDs, IP addresses, tokens, API keys, session IDs, database strings, local file paths, and request payloads. Preserve timestamps, levels, status codes, and error types when they are safe.
Package only the reviewed output
Copy or export the sanitised log. Before sending it to support, a vendor, or an issue tracker, scan once more for raw values, full local paths, and pasted private payloads.
Branch questions
Can the recipient still debug the issue from the sanitised log?
Do raw emails, tokens, session IDs, or local paths remain?
Completion check
Support boundary
Support can use by default
- Log type, approximate size band, and failed workflow step.
- Error category and redacted sample line after consent.
- No raw production logs or full local paths by default.
- Intent ID
- Article slug
- App route
- Browser and viewport
Requires your consent
- User-written description
- Email address
- Explicit attachment
- Redacted sample
- Support bundle previewed to the user
Not collected by default
- Raw original document text
- Full local file paths
- Pasted private content
- Unmasked screenshots
- Replay capture
Safe support summary
Copy a scrubbed handoff.
Redactorr KB support summary Article: /knowledge-base/log-files Selected issue: A supported log format fails to load or export. Playbook progress: 0/3 steps marked complete Safe context to include: - Log type, approximate size band, and failed workflow step. - Error category and redacted sample line after consent. - No raw production logs or full local paths by default. - Intent ID - Article slug - App route - Browser and viewport Requires explicit consent: - User-written description - Email address - Explicit attachment - Redacted sample - Support bundle previewed to the user Do not include by default: - Raw original document text - Full local file paths - Pasted private content - Unmasked screenshots - Replay capture User note: - Describe the step and symptom without pasting raw document text, secrets, files, or restoration material.
Article details
Sharing Logs Safely
Log files are essential for debugging, but they're also a goldmine of sensitive information. When you need to share logs with your support team or a vendor, you need to be careful.
What's Hiding in Your Logs?
Application and server logs often contain:
- User email addresses and usernames
- API keys and access tokens
- Database connection strings
- IP addresses and session IDs
- Error messages with personal data
- Request payloads with sensitive info
- Authentication credentials
- Internal server names and paths
A Risky Situation
You're having a problem with your app and need to send logs to your cloud provider's support team. But looking through the logs, you see:
- Customer email addresses from login attempts
- API keys from third-party integrations
- Database credentials in error messages
- User IDs and session tokens
- Internal IP addresses
You need help debugging, but you can't share all this sensitive data.
How Redactorr Helps
Upload Your Log File**
Drag your .log, .txt, or .json log file into Redactorr.
Format Detection**
Redactorr automatically recognises:
- JSON logs (structured)
- Plain text logs (unstructured)
- Common log formats (Apache, Nginx, etc.)
- Multi-line stack traces
Pattern Recognition**
The system finds sensitive data across:
- Log message bodies
- JSON field values
- Query parameters in URLs
- Header values
- Exception messages
Context Preservation**
Unlike simple find-and-replace, Redactorr:
- Keeps timestamps intact
- Preserves log levels (INFO, ERROR, etc.)
- Maintains request/response structure
- Keeps error codes and types
- Preserves the flow for debugging
Export Clean Logs**
Download sanitised logs that are:
- Safe to share with third parties
- Still useful for debugging
- Keeping all the structure and context
What Stays?
To keep logs useful for debugging:
- Timestamps
- Log levels (INFO, WARN, ERROR)
- Error types and codes
- Stack trace structure
- Request paths (with params redacted)
- Response codes
- Performance metrics
Use Cases
Sharing with Cloud Support: Remove your data while keeping infrastructure details visible.
Cross-Team Debugging: Share logs with contractors without exposing customer data.
Open Source Issues: Post logs to GitHub issues without leaking production secrets.
Compliance: Keep audit logs compliant by removing PII before archival.
Still stuck?
Copy a safe article handoff.
Start support with the article, the issue, and safe context. Raw document text, files, restoration material, and unredacted screenshots stay out unless you explicitly choose otherwise.
- Article slug
- Selected issue
- Screen name
- Action name
Redactorr support case Source: Article playbook: log-files Route: /knowledge-base/log-files Selected issue: A supported log format fails to load or export. Safe context: - Log type, approximate size band, and failed workflow step. - Error category and redacted sample line after consent. - No raw production logs or full local paths by default. - Article slug - Selected issue - Screen name or article section - Action name - Browser and viewport Only include with explicit consent: - User-written description - Email address - Explicit attachment - Redacted sample - Support bundle previewed to the user Do not include by default: - Raw original document text - Full local file paths - Pasted private content - Unmasked screenshots - Replay capture - Hidden diagnostic uploads User note: - Describe what you tried and what happened. Do not paste raw document text, secrets, files, restoration material, or unredacted screenshots.
Support case builder
One case format, wherever you start.
This is the same support case shape used by diagnostics and article handoffs.
- Log type, approximate size band, and failed workflow step.
- Error category and redacted sample line after consent.
- No raw production logs or full local paths by default.
- Article slug
- Selected issue
- Screen name or article section
Private material belongs behind an explicit consent step, not in the initial case.
6 default exclusions