Retry and drop classification
Transient 5xx retry with backoff; definitive 404 drops. Retrying deleted webhooks forever poisons queues.
Delivery failures differ; handling should too.
Classification
- 5xx/timeouts → retried bounded times.
- 404 (deleted webhook) → dropped permanently.
- Success → done; replays suppressed by dedup anyway.
Why this failure class persists
It helps to name the economics honestly. Fixing this class of leak costs minutes when caught at deploy time and days when caught at invoice time, because by then the credential has been harvested, validated, resold or drained — often all four. Detection latency is the entire game, which is why the monitoring half of KeyDrift exists alongside the scanning half.
How KeyDrift reports this exact finding
When KeyDrift finds this on your deployment, the report shows a masked value (first 8 and last 4 characters only), a salted fingerprint for tracking, the exact chunk filename carrying it, and a severity with written rationale. Public-by-design neighbours — anon keys, publishable keys, Firebase web constants — appear as informational context rather than noise, because knowing what should be there is what makes the real findings credible.
Manual check, step by step
A five-minute version you can run anywhere: view-source on the landing page, copy every src= script URL, fetch each and search the results for alert delivery retries. It misses manifest-only chunks and streamed payloads — which is precisely the gap between "I checked" and "it is clean" — but it catches the loud majority and builds the pattern-recognition that makes scanner output legible.
Close the loop with monitoring
Monitoring closes the loop that one-time verification leaves open. A scheduled scan refetches everything, diffs against history, and fires only on transitions: created, regressed, resolved. Regression alerts matter most here — they fire when a previously fixed finding returns, which in agent-era codebases is less a possibility than a schedule.
Where this fits
This document is part of the support knowledge base that mirrors production behaviour exactly: detector counts, plan limits and payload shapes on these pages are computed from the same catalogs that power the product, and tests assert they cannot drift. If anything here contradicts observed behaviour, report it via the false-positive process — calibration improves fastest when reality disagrees loudly.
Run a free scan at keydrift.dev/scan — paste a URL or the bundle source itself, no account. Findings arrive masked, with the exact chunk they live in.