LeakWatch looks for credentials that end up in public git, checks whether they still work, and tells you before a stranger finds them. Here is each part of that, mechanism by mechanism.
Figures frozen at build time (2026-08-17). The live feed is current to the minute.
These tools solve overlapping but different problems. This is where the lines actually fall.
| Criterion | LeakWatchHosted, watches public git | GitGuardianHosted platform, repo-integrated | GitHub secret scanningBuilt into GitHub | TruffleHog / gitleaksOpen-source CLI, you run it |
|---|---|---|---|---|
Finds leaks in repos you don't controlWhy it mattersMost keys leak from a fork, a contributor's own repo, or a snippet — not from yours. GitGuardian does watch public GitHub for an organisation's secrets, including developers' personal repositories, but that perimeter monitoring belongs to its business tiers rather than its free one. | Yes | Partial | No | No |
Verifies the secret is still liveWhy it mattersSeparates a real incident from a string that merely matches a pattern. TruffleHog verifies credentials against providers and can report only the verified ones; gitleaks matches patterns and does not check whether a key still works. | Yes | Yes | Yes | Partial |
Works without installing anythingWhy it mattersThe first scan should cost nothing but a URL. GitHub's scanning runs on repositories hosted there once enabled — it is on for public repositories, but it is not something you can point at an arbitrary repository from outside. | Yes | No | Partial | No |
Covers GitLab and CodebergWhy it mattersNot everything lives on GitHub. | Yes | Yes | No | Yes |
Full git history scanWhy it mattersDeleting the key in a later commit does not remove it from the clone. | Yes | Yes | Yes | Yes |
Detects your own secret formatsWhy it mattersAn internal service, a partner's API, a legacy key prefix — no scanner ships with a pattern for a token only your company issues. Custom detection is common; what differs is who can turn it on. GitGuardian's custom detectors are a Business-plan public beta, and a pattern is submitted as a request that their engineering team validates and deploys rather than something you switch on yourself. GitHub's custom patterns need Secret Protection (formerly Advanced Security) on an organisation-owned repository. The open-source CLIs take custom rules in a config file you own, but you still have to run them on every clone. | Yes | Partial | Partial | Yes |
Priced for a single developerWhy it mattersTeam-priced tools start above what a solo maintainer will pay. GitGuardian has a free tier for small teams; its paid plans are sold per developer seat and aimed at organisations. GitHub's secret scanning is free on public repositories. | Yes | Partial | Yes | Yes |
Compiled from each product's public documentation and pricing pages as of 14 August 2026, for their generally available offerings. These products change often — if a line here is out of date or wrong, write to [email protected] and it will be corrected.
| Feature | Free0€ · forever | Solo4.99€ · per month |
|---|---|---|
| Username check across public git | Yes | Yes |
| Affected repositories and severity | Yes | Yes |
| Deep scan (full git history) | 1 every 30 days | Unlimited |
| Commit URL and full secret | Deep scan only | Every leak |
| Liveness check (is the key still active?) | Deep scan only | Every leak |
| Free trial (14 days, monthly plan) | No | Yes |
| Continuous monitoring | No | Yes |
| GitHub App push-time monitoring | No | Yes |
| Email / Discord / Slack alerts | No | Yes |
| Dismiss a leak as a false positive | No | Yes |
| Public API access | 60 req/min, masked | 300 req/min |
A string that looks like an AWS key is a guess. A key the provider answers to is an incident.
A pattern scanner can help you detect strings that look like AWS keys, but it cannot tell you whether those keys are actually valid or still provide access. LeakWatch combines 372 detection patterns with 24 provider-specific validators. When a candidate is detected, the corresponding validator makes a single read-only request to the provider to check whether the credential is still accepted.
Supported providers and credential types include AWS, GitHub, GitLab, Stripe, OpenAI, Anthropic, Google, Azure, Discord, Telegram, npm, Hugging Face, database connection strings, private keys, and more.
That call is strictly read-only. Never a write, never a purchase, never a deletion: any credential we find is used exactly once, solely to check whether it is still active, and never again.
A secret deleted in the next commit is still in the history, and history is what an attacker clones.
Removing a key in a later commit does not remove it from the repository. Whoever clones gets every commit ever pushed, so the deleted line is still there,hidden in a `git log`. That's why a current-tree scan can come back clean even when a repository is still leaking secrets.
A deep scan mirrors the full repository, covering every branch, tag, and commit, not just the default branch. It runs in the background, typically taking about a minute, and up to 20 minutes for very large histories. You'll be notified when it's done. Scans run on public repositories you own; the clone itself is anonymous, just like any visitor. The free plan includes one deep scan every 30 days, while Solo removes the limit.
Install once, pick your repositories, and every push to them is checked as it arrives.
Signing in tells LeakWatch which accounts are yours. The GitHub App is what turns that into monitoring: you install it once, choose the repositories it covers, and repositories you create later can be included without going through the setup again.
It asks for two read permissions and nothing more — Contents (read), to see the code in the commits you push, and Metadata (read), which GitHub requires of every app. No write access, no issues, no actions, no ability to change anything in your repository. On each push GitHub delivers a webhook, the scan is queued on the spot, and the alert follows the scan: there is no polling interval to wait out and no crawl scheduled behind it. Uninstalling the app from your GitHub settings revokes the installation token immediately, and monitoring stops with it.
Email, Discord or Slack — with the provider, the repository, the commit and the revocation steps in the message.
An alert should let you act without investigating first. Each one names the provider and the kind of credential, the repository and the exact commit, and shows the secret masked — enough to recognise the key, never enough to use it. It ends with the link to that provider's own revocation page. The same secret across ten commits is one alert, not ten.
Everything the dashboard shows is available under /api/v1, keyed to your account.
Findings go where you already look: a CI job that fails a build on a live key, a SIEM, an internal dashboard. REST and JSON with a published OpenAPI schema — scans, monitored repositories, your own leaks, the public feed and the detector catalogue are all endpoints. Keys are created and revoked from your dashboard and shown once, at creation.
Type a username and you see, without an account, how many secrets tied to it are already public and how bad they are. Sign in and one deep scan of your full git history, every 30 days, stays free too. Continuous monitoring is what a subscription adds; the first look never costs anything.
Check a username