RETROSPECTIVE RECORD · PREPARED 16 SEPTEMBER 2026The archive · 200 retrospective records ↗

The archive / Support & operating load

Support & operating load / Operating entry · Entry note · prepared 16 September 2026

Have I Been Pwned admits its own breach coverage is partial

Have I Been Pwned's own API docs and FAQ state what breach monitoring covers, what it costs, and what it admits it misses.

Visual for this record: have-i-been-pwned-breach-monitoring-service-for-founders
Visual published by haveibeenpwned.com, shown for identification of the record. Credit: haveibeenpwned.com · source page ↗ Rights: owner-review-pending.

The workload

Have I Been Pwned, the breach-notification service run by Troy Hunt, lets a founder check whether their own accounts or their product's user base appear in a known data breach. Using it as intended is a recurring task rather than a one-time lookup: new breaches are added on an ongoing basis, so a domain or address that returns clean today can return a match after the next large breach is indexed.

What the documents show

Verified: the service's own API documentation states that individual email address searches remain free, that the separate Pwned Passwords API requires no authorisation and carries no rate limit, and that domain search, paste lookups and higher-volume access sit behind paid Core, Pro and High RPM subscription tiers, with domain ownership verified by DNS or email before results are returned. Verified: the service's own FAQ states plainly that “HIBP contains but a small subset of all the records that have been breached over the years,” and that some breaches are withheld from public search entirely for sensitivity reasons, with access to those requiring a signed-in, verified account. The FAQ also notes that “many breaches never result in the public release of data and indeed many breaches even go entirely undetected,” a direct statement of the service's own coverage limit rather than a criticism from outside it.

The operating cost

Verified: checking a single email address costs nothing. Verified as a stated tier structure, not a specific price: verifying and monitoring an entire domain, the more relevant workload for a founder watching a product's user base rather than one inbox, requires a paid Core, Pro or High RPM subscription, with exact pricing directed to a separate pricing page the API documentation references but does not itself state.

The stop condition

Neither document states a point at which monitoring should stop. Editorially: given the FAQ's own admission that coverage is partial and some breaches go undetected entirely, the more defensible framing is that this workload has no natural end while a product still holds user credentials; the practical question is not when to stop but how often a domain gets re-checked, a cadence the documents leave to the operator.

  • Is the domain search set up for the product's actual user-account domain, or only for founder-owned addresses?
  • What is the plan for a positive match: forced password resets, user notification, or something else, and who owns executing it?
  • Does the subscription tier in use actually cover the breach types, such as stealer logs, most relevant to the product's risk?

Have I Been Pwned documents what it monitors and, just as plainly, what it does not; treating a clean result as proof of safety rather than as a partial, point-in-time check is the specific mistake its own FAQ warns against.

Sources & reading trail

Have I Been Pwned: API v3 ↗

States free versus paid access, domain-verification process and rate-limit behaviour.

Source published: Not established · Retrieved: 16 September 2026

Have I Been Pwned: FAQs ↗

States the service's own admitted coverage limits and handling of sensitive breaches.

Source published: Not established · Retrieved: 16 September 2026

Vendor documentation, regulator records and founder-published documents establish the entry; the workload reading and the stop condition are Solo Product Office editorial analysis. This retrospective draft does not imply the site published on the event date.