Is it safe to paste that log?

You hit an error, you have a stack trace, and you want to put it in a bug report, a forum thread, a pastebin or an AI chat. Here is what is actually in that text, what an automated scrubber can and cannot take out of it, and the one step people skip.

The short version. Logs leak far more than the error you are trying to fix. Assume the text contains at least one credential, one email address and one internal hostname until you have looked.

And the step people skip: if a live credential was in the log, redacting your copy does nothing about it. Redaction protects the next reader. Only rotating the credential protects you. Do that first, then paste.

Where you paste it decides what “undo” can mean
  1. ReversibleYour own terminal Undo: close the window.
  2. ReversibleA file on your own machine Undo: delete it — unless it is inside a folder that syncs to a backup.
  3. PartlyA private ticket in a tracker you control Undo: delete the ticket. Notification emails already left the building, and whoever was watching has a copy in their mailbox.
  4. PartlyTeam chat, or an AI assistant Undo: delete the message. Search indexes, desktop caches and retention windows are outside your reach, and on somebody else’s service so is the timing.
  5. Assume notA public paste, gist or screenshot host Undo: delete the paste, and hope. Automated scanners poll these endpoints continuously and specifically. Deletion is a race you are not winning.
  6. Assume notA public issue, forum post or commit Undo: none that you can rely on. Assume it is indexed, mirrored and archived from the moment it is visible.
→

The ladder is why the order matters. Redacting decides what the next reader sees; it does nothing about the copies that already left. If a live credential was in that text, rotate it first, then paste.

Where you paste changes what “undo” means

Every option below leaks the same text. They differ in who reads it and in whether deleting it afterwards accomplishes anything.

WhereWho can read itDoes deleting help?
Private ticket Your org now, plus everyone who joins later, plus anyone who exports the tracker. Partly. Edit history and search indexes often keep the original.
Public issue
or forum		 Everyone, plus crawlers and mirror sites within minutes, plus every subscriber who got an email copy of your post. No. The email notifications already went out with the full text.
Gist or paste,
“unlisted”		 Anyone with the link. Unlisted is not private, and public paste sites are continuously scraped by people looking for exactly this. No. It removes the page, not the copies.
AI chat The vendor, under whatever retention and training settings your account has. Worth checking those settings once rather than guessing each time. Assume the message was stored the moment you sent it.
CI log On a public repository, everyone. Build logs are indexed and archived. No, and re-running the job does not remove the old run.

In every row, the remedy for a leaked credential is the same, and it is not deletion. It is rotation.

What actually leaks out of a log

Each example below is a real log shape. The badge says whether an automated redactor — specifically the one on this site, which runs offline in your browser — catches it, and every badge on this page is verified by a test that runs the example through the actual detectors before publishing.

1. Credentials that look like credentials caught

fatal: could not read Password for https://github.com: ghp_A1b2C3d4E5f6G7h8I9j0K1l2M3n4O5p6Q7r8

Prefixed tokens are the easy case: ghp_, AKIA, sk_live_, xoxb-. They are easy for a scrubber to find and equally easy for someone scanning public pastes to find. If you want to know what a particular prefix lets an attacker do, that is the field guide.

2. Credentials that do not look like credentials caught

java.sql.SQLException: jdbc:postgresql://reporting:Tr0ub4dor3@db-prod-3:5432/analytics
mysql -h db-prod-3 -u reporting --password=Tr0ub4dor3 analytics

This is the category people under-estimate. A password inside a connection string, a password on a command line captured by a shell trace, an Authorization: Basic header whose base64 decodes to user:password. None of these have a memorable prefix, and all three appear in ordinary crash output without anyone deciding to log a secret.

3. Session tokens, including expired ones caught

session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MjciLCJ0ZW5hbnQiOiJub3J0aHdpbmQiLCJyb2xlIjoiYWRtaW4ifQ.QW5vdGhlclNpZ25hdHVyZUhlcmU

A JWT is signed, not encrypted. The middle section is plain base64 and anyone can read it without any key at all — here it says user 427, tenant northwind, role admin. So “it is expired, it is fine” is only half true: the token may no longer authenticate, but it still publishes your internal id scheme, your tenant names and your role names.

4. People caught

File "/home/rmalone/src/billing/app.py", line 214, in charge
DEBUG notify: sending receipt to rachel.malone@northwind-logistics.com

Stack traces carry the developer's username in every file path, and application logs carry the customer's email in every notification line. The first tells a stranger who works there and what the internal project layout is; the second is somebody else's personal data, which your organisation probably has rules about.

5. Payment and identity data caught

PaymentError: card 4242424242424242 declined

Card numbers and social security numbers turn up in payment-path exceptions surprisingly often, because the failing request body gets logged whole. A good redactor checks the Luhn digit rather than matching any sixteen digits, so order numbers survive and cards do not.

6. Your internal map not caught

ConnectionRefusedError: connect to redis-sessions-prod-2.internal:6379 failed
AccessDenied: s3://northwind-invoices-prod/2026/08/batch-441.csv
sqs consumer error on queue billing-retries-prod-dlq

Hostnames, bucket names, queue names, database names, service names. No scrubber can find these, because they are indistinguishable from ordinary words — only you know that northwind-invoices-prod is a bucket rather than a variable. Individually they are harmless. Collectively they are a map of your infrastructure with the production systems helpfully labelled, and that is what makes the next phishing attempt convincing.

This is the part you have to do by hand. It is the single biggest reason not to treat “I ran it through a redactor” as finished.

7. Private IP addresses not caught, on purpose

ConnectionRefusedError: [Errno 111] connect to 10.4.19.203:6379 failed

The redactor on this site skips RFC1918 ranges — 10.x, 192.168.x, 172.16–31.x, 127.x — because redacting every internal address makes a network log unreadable while hiding nothing an attacker could route to. Public addresses like 203.0.113.44 are redacted. If your internal addressing is itself sensitive, that is a decision only you can make, and you make it by reading the output.

8. Version fingerprints not caught

Python 3.11.4 / Django 4.2.1 / psycopg2 2.9.6 / nginx 1.24.0

The banner at the top of a traceback is an exact inventory of what you run. No tool will ever flag it, because it is indistinguishable from the information you are asking for help with. Usually you should post it anyway — people cannot help you without it. Just know that you are also publishing a list someone can check against known vulnerabilities, and weigh that if your stack is behind on patches.

What a redactor cannot do for you

Automated scrubbing is worth doing and is not sufficient. The honest limits:

The two-minute procedure

  1. Rotate first, if there was anything real. If you can see a live credential in the original text, revoke it now, before you finish reading this page. Every other step is about the copy you are sharing; this one is about the key itself.
  2. Scan the text. Paste it into a redactor and get the mechanical categories out of the way.
  3. Read the output rather than skimming it. You are looking for one thing: anything still readable that you cannot explain. Half-redacted tokens hide here.
  4. Do the pass a tool cannot do. Hostnames, buckets, queues, database and service names, internal URLs, ticket numbers, customer names in free-text fields.
  5. Trim to the failure. Most of a log is not evidence. The fewer lines you post, the smaller every one of these problems gets, and the more likely you are to get a useful answer.
  6. Then paste.
Scrub a log now → The Log Redactor: paste a log, get a copy-safe version with credentials, tokens, passwords, emails and addresses replaced by labelled placeholders. Runs entirely in your browser, makes no network requests, and repeated values keep matching numbers so the log still reads correctly afterwards.

If it is already public

Order of operations, and the order matters:

  1. Rotate the credential. Not delete the post — rotate. Assume the text was scraped within minutes of going up, because for public paste sites and public repositories that is a fair assumption.
  2. Work out what that credential could do while it was live. Different prefixes have very different blast radii; the field guide goes through them one at a time.
  3. Check the logs on the other side — the provider's audit trail for that key, for use you did not make.
  4. Then delete the post, and edit the git history if it was committed. Cleanup is last because it is the step that does the least.

Preventing the next one

If you are the one designing the API whose keys keep showing up in other people's logs, the format is a lever. A distinctive prefix makes a leak findable by automated scanners, and a short checksum lets a scanner reject a fake without a network call. How to design an API token covers both, with tested reference code in JavaScript and Python.

If it is already out there — committed, pushed, pasted — then this page is the wrong one and the clock has started. Do these things, in this order.