Share logs without leaking credentials

Guide · updated October 2026 · 3 min read

Logs are the most useful thing to share when something breaks, and the most dangerous thing to paste by accident. A stack trace is harmless; the twenty lines around it often contain an authorization header, a session cookie, a customer email and an internal hostname. The fix is a two-minute routine, not a policy document.

Redact before you paste

Read the block once, top to bottom, looking only for these:

Pattern	What it looks like	Replace with
Bearer tokens, API keys	`Authorization: Bearer sk_live_…`, `ps_…`	`Bearer [REDACTED]`
Passwords, secrets	`password=`, `client_secret`, `-----BEGIN … PRIVATE KEY-----`	`[REDACTED]`
Session cookies	`Cookie: session=…`, `Set-Cookie`	`[REDACTED]`
Email addresses	anything matching `name@example.com`	`user@example.com`
IP addresses	`203.0.113.42`	`203.0.113.0` (documentation range)
Customer identifiers	user ids, order ids, phone numbers	`user_1234` style placeholders
Internal hostnames	`db-prod-3.internal`	`db.internal`

If a real credential did go into a paste, rotate it. Deleting the paste is not enough: the link may already be in a chat, a ticket or a browser cache.

Trim the log first

Nobody needs 40,000 lines. The error plus a few hundred lines of context is usually enough, and a smaller paste gets read faster.

Trim and redact in a shell

# last 300 lines of a log
tail -n 300 app.log > /tmp/clip.log

# from the first error onward
awk '/ERROR/{found=1} found' app.log | head -n 400 > /tmp/clip.log

# strip common secrets before pasting
sed -E 's/(Bearer|token|password|secret)=?[^ ,"]+/\1=[REDACTED]/gi' /tmp/clip.log > /tmp/safe.log

Keep the timestamps. They are what makes a log useful — they let the reader line the failure up with a deploy, a request or another service.

Choose link settings that match the content

Language: plain text for most logs. Choose JSON if every line is a JSON object, or Bash if it is shell output with commands.
Visibility: unlisted. There is no reason for a debug log to appear in the public feed.
Expiry: a day or a week is plenty. Debugging ends; the log should too.
Password: for logs from a production system, add one and send it separately.
Burn after read: for a single debugging exchange, this removes the paste the moment your colleague opens it.

A paste is not encrypted at rest beyond the provider's disk encryption, and the link is the only access control besides the password. Treat it like a shared document with a long URL, not like a secret store.

What not to share at all

Some logs should never leave the environment, even redacted: authentication logs with session material, payment processor payloads, anything covered by a compliance regime you are subject to, and logs containing health or financial data about identifiable people. In those cases, reproduce the failure with synthetic data and share that instead — it usually produces a clearer paste anyway.

Frequently asked questions

How big can a log paste be?

100,000 characters, roughly 1,500–2,000 log lines depending on line length. Trim with tail or awk before pasting if you are over that.

Can I delete a log paste after sharing it?

If you created it while signed in, yes, from your dashboard. Anonymous pastes cannot be deleted by their creator — use an expiry, or burn-after-read, so the content goes away on its own.

Is it safe to paste a stack trace publicly?

Usually, if it contains no credentials, customer data or internal hostnames. File paths and library versions are low risk. When in doubt, mark the paste unlisted and set an expiry.

Does the site index paste pages?

Paste pages are excluded from search engines via robots.txt, and unlisted pastes never appear in Recent or Trending. A link still works for anyone who has it.