Sensitive monitor data
How DiffMon handles monitor credentials, headers, payloads, retention, and deletion.
Before you monitor sensitive systems
DiffMon can monitor authenticated APIs and pages, which means customers may configure monitors that touch protected systems or sensitive responses. Before doing that, understand what configuration is stored, whether full bodies may be retained, and how to reduce unnecessary exposure.
For the broader buyer-facing overview, see Security.
What may be sensitive in a monitor
- bearer tokens
- cookies
- API keys
- custom auth headers
- signed URLs
- request bodies
- response bodies
- customer or internal data present in monitored payloads
Only put secrets into a monitor when they are required for the check.
Authentication and custom headers
- Values entered in the Auth tab are treated as secrets for outbound monitor requests.
- Monitor authentication secrets are encrypted at rest.
- After save, plaintext secret material is not returned back into the UI.
- Values entered in raw custom headers are stored as monitor configuration, so do not place broad reusable secrets there unless the monitor truly requires them.
- API tokens are handled separately and are stored as irreversible hashes. See API tokens.
Treat bearer tokens, cookies, and custom auth headers as stored secret material and prefer the least-privileged credential that still allows the check.
When response bodies may be stored
- In Content mode, DiffMon may store response bodies and derived diffs so it can compare changes over time.
- In Headers only or Status only mode, DiffMon avoids storing body content for that monitor.
- Both current and changed artifacts may exist inside the retention window where evidence or diff history requires them.
- Diff metadata and run metadata are not the same thing as full payload storage.
Do not assume âwe never store bodiesâ for monitor modes that are designed to preserve evidence.
How to minimize stored sensitive data
- Put secrets in the Auth tab, not raw headers, whenever the monitor type supports it.
- Use Headers only or Status only mode if body content should not be stored.
- Use extract and ignore rules to minimize the retained portion of a response.
- Limit workspace access to users who need monitor configuration or payload visibility.
- Rotate credentials when personnel or vendors change, and revoke unneeded API tokens and webhook secrets promptly.
For especially sensitive environments, avoid monitoring endpoints whose responses contain secrets, regulated personal data, or internal-only documents unless you have reviewed the storage and retention implications.
Browser-render considerations
Browser-render monitoring has a larger runtime surface than a simple HTTP fetch. DiffMon uses isolated browser contexts, avoids persisted cookies or local storage between runs, and blocks unsafe schemes and file access. That reduces persistence risk, but it does not eliminate the need to think carefully about what the monitored page itself contains.
Retention matters more for sensitive monitors
Snapshot, diff, and payload retention follows your workspace plan. See Retention.
- Free - 3 days
- Hobby - 30 days
- Pro - 180 days
- Business / Enterprise - custom
When retention expires, payload blobs are deleted while some operational metadata can remain for integrity and audit purposes. Payload deletion and snapshot metadata lifecycle are not always identical.
Operator FAQ
What if I place a bearer token in monitor auth?
Treat it as stored monitor secret material and review the credential scope carefully.
What if I add a secret in a custom header?
Only include it when necessary. Prefer the least-privileged credential and avoid broad reusable tokens.
Are response bodies always stored?
No. Storage depends on monitor mode and product behavior, and body-minimizing modes are available for less sensitive use cases.
Can support see my secrets or payloads from the support form?
The support intake flow excludes auth headers, cookies, snapshot payloads, and webhook URLs.