FAQ¶
Quick answers to questions that come up repeatedly. If yours isn't here, email [email protected].
Account & billing¶
Can I change plans at any time?¶
Yes. Upgrades take effect immediately. Downgrades take effect at the end of your current billing period. Manage from Billing → Manage subscription.
What happens to my data if I downgrade and exceed the new plan's limits?¶
Your existing findings remain. Repos and domains over the new limit are not automatically removed, but no new scans will run on the over-quota items until you bring usage back under the limit (disable some repos / remove some domains) or upgrade again.
What happens if I cancel?¶
Your account stays active until the end of the billing period, then transitions to Free. If you also cancel the Free tier, after 180 days of inactivity the account is soft-archived — repos disabled, tokens cleared, data retained for an additional 90 days then permanently deleted.
To request immediate deletion, see Right to deletion.
Right to deletion¶
Email [email protected] from the email on file requesting account deletion. We'll confirm the request, run the purge within 5 business days, and send confirmation. The purge cascades through all your findings, scans, audit logs, and integration credentials.
For Enterprise customers with contractual retention terms, we follow the contract.
Scanning¶
Why does a scan show "Interrupted"?¶
We've worked hard to make this rare. When it happens, it usually means one of:
- Worker died unexpectedly. We retry up to 3 times automatically — the badge means all 3 retries failed.
- GitHub kept us rate-limited beyond a recoverable window (very rare with our current pacing).
- Your GitHub token was revoked mid-scan — re-paste a fresh token under GitHub → Private repo token.
Findings discovered before the interruption are still saved. The next scheduled scan starts fresh and does not count against your quota.
Why does my scan take so long?¶
A first scan of a 50-repo account: 15–30 minutes. A first commit-history scan of a large monorepo: hours, in 5-minute chunks running in the background. Subsequent scans are much faster because everything is incremental — we only scan new commits since the last watermark.
Web scrapes vary widely depending on how many subdomains a domain has (we discover them automatically — popular SaaS domains can have 100+).
Why isn't a specific repo being scanned?¶
Check, in order:
- Is the repo enabled on the GitHub → Repositories page?
- Is your stored GitHub token still valid? (GitHub → Private repo token — should show green ● Configured.)
- Does your token have
repo(classic) orContents: Read-only(fine-grained) scope? - Are you within your daily scan quota? (Visible on the Scans page.)
Why does CredWatch sometimes ignore a file?¶
We skip:
- Files larger than 500 KB (likely binaries or generated bundles).
- Files outside our list of "interesting extensions" (config, code, key files). Things like
.png,.mp4, compiled binaries are skipped. - Repos containing more than 500 files (we cap at the first 500 — relevant only for very large monorepos).
If you have a specific scanning requirement, email us.
Can I trigger a scan from my own tooling?¶
Not yet via the API (that endpoint isn't public yet). Today you can:
- Click Run scan now in the portal.
- Use the CI/CD pre-merge scanner to scan PR diffs.
If programmatic scan-trigger is important for your workflow, email us — it's on the roadmap and customer demand affects priority.
Findings¶
Why is the same key showing as 50 findings?¶
Because it appears in 50 places (different files, different commits, etc.). Each location is one finding. Rotating the key once and clicking Resolve on one finding doesn't auto-resolve the others — you need to mark each. Use the "Also found at" card on the detail page to see siblings and act on them quickly.
We're working on a "resolve all siblings" bulk action — not shipped yet.
Why was my finding auto-resolved?¶
If a credential is gone from the source on the next scan (e.g. you removed the file, force-pushed, or rotated and re-deployed), CredWatch marks the finding resolved with a resolution_note like "Auto-resolved: not found on rescan 2026-05-21".
If we were wrong — the credential is still exposed somewhere we didn't see — let us know. This is rare but it can happen if a file moved without us seeing the move.
Why does a finding show validation_status: unvalidated?¶
Either:
- We don't have a validator for that secret type yet, or
- The network call to the issuing service failed (rare, transient).
You can recheck validity manually from the finding detail page.
Why isn't a clearly-real key being detected?¶
Likely we don't have a pattern for that secret type. Check Patterns in the portal — the list of standard patterns we ship is shown there. For company-specific patterns, add your own custom pattern.
If you think we should have shipped a pattern for it, email us with an example masked value and we'll consider adding it to the standard set.
Integrations¶
Slack messages aren't arriving¶
- In CredWatch: Profile → Notifications → Slack — click Send test. Should appear in Slack within 5 seconds.
- If the test doesn't arrive: regenerate the incoming-webhook URL in Slack (someone may have revoked the old one) and paste the fresh one.
- If the test does arrive but real alerts don't: check the alert score threshold (default 60). Your findings may all be under threshold.
My webhook endpoint keeps timing out¶
Our timeout is 10 seconds. If your endpoint takes longer:
- Don't do synchronous work in the handler. Accept the request, queue it, return 200 immediately.
- Verify the signature first, then return 200, then process asynchronously.
- We don't retry — once the timeout fires, the event is dropped permanently.
PagerDuty integration test works but real alerts aren't firing¶
PagerDuty only fires for score ≥ 90 + validation = valid + status = active. Lower-severity findings don't page. This is intentional — you should be able to leave PagerDuty on without being woken up for medium-severity findings.
If you want a lower threshold, use Slack or email instead. PagerDuty is for "wake up the on-call".
Security & compliance¶
Do you SOC 2 / ISO 27001?¶
We've implemented every mandatory control for both frameworks (audit log, encryption at rest, MFA, RBAC, retention, incident response, vendor risk management, data classification, etc.) and we're on a path to formal certification. We can share our internal controls documentation under NDA for Enterprise prospects.
If you need formal SOC 2 Type II / ISO 27001 reports today and we don't have them yet, email [email protected] — we'll share where we are in the audit timeline.
Where is my data stored?¶
Today: a single VPS in Western Europe. PostgreSQL primary + daily backups; Redis for queue state. We're on a path to AWS (multi-AZ RDS in eu-west-1) when scale demands.
Enterprise customers with data-residency requirements can request a deployment in a specific region or a self-hosted / VPC deployment — see the Enterprise tier on the pricing page.
What credentials do you have access to?¶
For each customer:
- Your GitHub PAT (Fernet-encrypted at rest, decrypted only during scans).
- Your webhook/integration secrets (same).
- Your portal login credentials (bcrypt-hashed; we never see plaintext).
We do not have access to the raw credentials we find for you — those are masked to 8 plaintext characters max before storage.
How do I rotate my CredWatch credentials?¶
- Portal password — Profile → Change password.
- GitHub PAT — generate a fresh one in GitHub, paste it under GitHub → Private repo token.
- API keys — Profile → API keys → Generate new then revoke the old.
- Webhook secret — Profile → Outbound webhook → Rotate secret.
- MFA secret — disable, then re-enable to provision a fresh QR / recovery codes.
Still didn't find your answer? Email [email protected].