Your traffic is your most sensitive data. We treat it that way.
Capture that can include bodies deserves controls that start before the data moves. Redaction and exclusion run inside your Node process, so masked values never leave your network.
What we do, specifically
Redaction runs in your process
Rules are applied inside your Node process, before transmission. Mask a header, a field name or a JSON path and the value never leaves your network - there is no copy of the original on our side, because we never received one.
Bodies are off by default
Body capture is opt-in, per route. Headers are allow-listed rather than blocked, so you name what we keep instead of trying to enumerate what we should not.
Exclusions drop routes entirely
Health checks, internal admin, anything you have decided should never be recorded - excluded routes are not captured at all rather than captured and filtered later.
Nothing ships before rules load
The SDK does not transmit until your account’s redaction rules have loaded. A cold start cannot race the rules and leak an unmasked payload.
A kill switch that does not need us
API_TRAFFIC_WAF_ENABLED=false takes effect without a deploy and without reaching our API - which is the case that matters when we are the thing going wrong.
Access control
Account roles (owner, admin, member) and enforced MFA. Per-bucket access control and SSO are on the roadmap.
The best way to protect a secret is never to send it
Redaction is not a post-processing step on our side. It is part of the SDK, so a masked field is masked in the payload that leaves your process - and there is no copy of the original anywhere.
Body retention is a separate entitlement from metadata retention, so searchable metrics and captured bodies can expire on different schedules.
Need a DPA, our sub-processor list, or a questionnaire completed? Email [email protected].
// applied in-process, before transmission redactions: [ { path: '$.card.number', mode: 'mask' }, { header: 'authorization', mode: 'drop' }, { path: '$.user.ssn', mode: 'hash' }, ]
How long we keep it
Metadata, bodies and spans are separate entitlements with separate windows.
Request metadata
Kept for your plan’s retention window and then expired. Each plan’s window is listed on the pricing page.
Captured bodies
Only captured where you turn body capture on, and kept on their own schedule - separate from metadata, so bodies can expire long before the record does.
APM spans
A separate entitlement again, with its own window: span detail can age out without taking the request history with it.
Deletion
When an account is closed, its telemetry is deleted. Records we are legally required to keep, such as invoices, are kept only for as long as that requirement lasts.
Encryption
Data is encrypted in transit and at rest. Authentication secrets - MFA secrets, phone numbers, backup codes - are encrypted with a separate key from ordinary account data.
The documents a security review wants
Small teams get security questionnaires too. Ask and we will send what we have - and say plainly what we do not.
Data Processing Agreement
Ask, and we will tell you what we can sign and on what terms.
Architecture overview
Data flow, storage tiers, retention and isolation model.
Redaction guidance
How to prove to a reviewer that a field never left your network.
Vendor questionnaire
We will complete yours, or send our standard responses.
Incident response policy
Notification commitments and escalation path.
Retention configuration
Written confirmation of the retention set on your account.
Prove it on a staging service first.
Install the middleware, mask what you never want captured, and see exactly what we store before anything touches production.
Free trial · No credit card · Set up in minutes