Keeping PII out of your error tracker (a practical guide)

Your error tracker sees everything your app sees at the moment things go wrong — and that's exactly the problem. A single unhandled exception can carry the request body, headers, query string, and a stack trace full of local variables. Somewhere in there is a customer's email, a session token, maybe a card number. PII redaction is the practice of scrubbing that sensitive data before it's stored, so debugging an error never turns into a data-breach waiting to happen. This guide covers where personal data hides in error payloads, the strategies that actually keep it out, and how to think about retention.

Where PII actually hides

It's rarely where you expect. The obvious spots are easy to remember; the leaky ones aren't:

• Request bodies — the form the user just submitted, password fields included.
• Headers — Authorization, Cookie, and custom API-key headers.
• Query strings — tokens and emails passed in URLs.
• Stack frame arguments — the $user object three frames down, fully serialized.
• Custom context — the extra data you attach to "make debugging easier."

If you only redact the request body, you've missed four other doors.

Strategy 1: redact at the source, before it leaves the app

The safest place to scrub data is inside your own process, before anything is sent over the wire. A good SDK lets you declare sensitive keys and patterns so they're masked at capture time. With Lookout's Laravel package you configure this once:

composer require lookout/tracing
php artisan lookout:install

From there you set which keys to mask and which patterns (emails, tokens, card-like numbers) to catch, so a field named password or anything matching a credit-card shape never serializes into an event. Redact-at-source means even your network never sees the raw value.

Strategy 2: deny by default for high-risk fields

Allow-listing beats deny-listing for the dangerous categories. Instead of trying to name every sensitive field, mask whole classes of data and explicitly opt specific fields back in. Authorization headers, cookies, and anything that looks like a secret should be masked unless you've deliberately allowed it. You'll never remember to add x-internal-token to a block list — but a deny-by-default rule catches it for free.

Strategy 3: limit retention so old data isn't a liability

Data you no longer hold can't leak. Redaction handles what you store; retention handles how long. Set a window that matches how you actually debug — most teams resolve issues from the last few days, not the last few months — and let older events age out automatically. Lookout supports configurable retention so events expire on a schedule instead of accumulating forever. Shorter retention also keeps your dashboard fast and your storage bill honest.

Strategy 4: make redaction verifiable

A redaction rule you can't see is a redaction rule you can't trust. After you configure masking, deliberately throw a test error containing a fake email and a fake token, then open the event and confirm both come through as masked. Treat it like any other piece of code: if it isn't tested, assume it's broken. Re-run that check whenever you add a new field to your request payloads.

A quick checklist

• Mask request bodies, headers, query strings, and stack-frame arguments.
• Deny-by-default for auth headers, cookies, and secret-shaped values.
• Set retention to match your real debugging window.
• Throw a test error with fake PII and confirm it's scrubbed.
• Re-verify whenever your payloads change.

Good observability shouldn't force you to choose between fixing bugs and protecting users. Redact at the source, deny by default, keep retention tight, and verify it — and your error tracker becomes an asset instead of a liability. Lookout ships with PII redaction and configurable retention built in, and the free Starter tier (10,000 events/month, one project, no credit card) is enough to wire it up and watch a fake email get masked in real time. Create a free project and test your redaction today.