BreachDirectory Not Working? Common Problems and Troubleshooting Steps
November 6, 2026 · Updated November 6, 2026 · Suman Lama · 10 min read · BreachDirectory · For developers
You open BreachDirectory, submit a search, or run an integration, and something does not work. Perhaps the page never loads, a search stays pending, or your application returns an error instead of exposure information.
Before changing settings or repeating the request, identify which part failed. A website-loading problem, rejected query, API authentication issue, and browser CORS restriction require different investigations.
A failed lookup means the exposure result is unknown. It does not mean that your address was checked and found safe.
This guide provides a structured troubleshooting approach for readers and developers. It is not a live status report, a verified list of current BreachDirectory errors, or confirmation that the service is experiencing an outage.
Identify the Exact Service First
This article refers to BreachDirectory associated with breachdirectory.org, whose privacy policy identifies the operator and covered site. Third-party tools, API marketplace listings, and similarly named domains should be evaluated as separate interfaces. Source: BreachDirectory privacy policy
Record where the failure occurs. Are you on the provider's public website, using an application that calls an upstream API, or accessing a marketplace subscription?
A tutorial written for another provider or an older endpoint may no longer describe your setup. Avoid replacing a failed destination with a similarly named site simply because its page loads.
For integration background, see our BreachDirectory API overview.
Start With the Symptom
| Symptom | What to establish first | What not to conclude |
|---|---|---|
| Website will not open | Whether this is a local connection, browser, access, or service problem | That the service is down for everyone |
| Page loads but search never finishes | Whether the search request completed | That there are no matches |
| Input is rejected | Whether the current feature accepts that identifier and format | That the identifier has never been exposed |
| Access or authentication message | Whether the feature's documented requirements are satisfied | That a new key or repeated request will necessarily solve it |
| API returns an error | Exact endpoint, status, content type, and redacted error details | That every error has the same cause |
| Browser reports CORS | Whether the cross-origin request is permitted by the server | That browser security should be disabled |
| Third-party app shows empty results | Whether its upstream request actually succeeded | That its empty display is a trustworthy negative lookup |
These are diagnostic categories, not promises about current BreachDirectory screen labels.
If the Website Will Not Load
Check the address you entered and whether other ordinary websites load on the same device. If your connection is unavailable generally, restore normal connectivity before investigating a single service.
If the rest of the web works, note the exact visible message. A DNS failure, certificate warning, access restriction, and server error describe different problems. Do not replace them with the single explanation “the site is hacked” or “the site is down.”
One ordinary reload can help distinguish a transient loading issue. Repeated rapid refreshes are unlikely to provide a better diagnosis and may add unnecessary traffic.
If a browser-generated certificate or security warning appears, stop rather than bypassing it to submit personal information. If a workplace network restricts the destination, ask the network administrator about the approved process instead of attempting to evade the restriction.
An inability to reach the service does not answer the exposure question. You can still protect your accounts while deciding whether to return later or use another documented provider.
If the Page Loads but Search Does Not Finish
First, check the input. Use the identifier type the current feature actually supports, and look for accidental spaces or a mistyped domain.
Next, look for a validation message, request limit, sign-in requirement, or service notice. Follow the instructions for that feature rather than assuming the search is available under an old tutorial's conditions.
A clean browser profile can sometimes help investigate a local configuration issue, but it is not a way to bypass provider restrictions. Keep security protections enabled and do not install an unfamiliar extension offered as a universal fix.
If you choose to clear site data, understand that it may end the site's session or remove local preferences. Do not clear unrelated browser information as a first response to a single failed search.
If the lookup remains incomplete, record the outcome as unknown. Do not keep submitting different personal details just to produce a response.
Does an Access-Denied Message Mean Your Address Was Found?
No. An access decision concerns whether the request may proceed, not whether the submitted identifier appears in breach records.
A blocked or forbidden response can have several causes. The response and current documentation are the starting points for determining which applies. A bare status code does not establish a bot challenge, invalid subscription, geographic restriction, or specific account problem without additional evidence.
Respect the service's access controls. Do not rotate identities, accounts, keys, or network paths to get around a restriction.
If support is available, provide the time, affected feature, and a redacted error description. Do not send your mailbox password, recovery codes, or full authorization header.
Developer Check 1: Confirm the Endpoint and Authentication
Start from current documentation for the exact provider and access path. Confirm the base URL, route, HTTP method, authentication mechanism, required headers, and subscription permissions.
Do not assume that a public website query and a marketplace API share endpoints, credentials, or access terms. An example copied from an old repository may be useful historical context without being current documentation.
Check that the application is using the intended environment configuration. A deployed application and a local development server can have different variables or credentials.
Keep secrets out of browser bundles and public source code. If a key has been exposed, use the provider's normal revocation and replacement process instead of continuing to troubleshoot with a compromised credential.
Avoid logging entire URLs if query parameters contain personal identifiers. A useful diagnostic record can usually capture the endpoint category, status, timing, and a redacted error without retaining sensitive request data.
Developer Check 2: Interpret HTTP Statuses Carefully
HTTP response codes provide useful context, but an API's documented contract determines the meaning of a completed lookup.
| Status | General HTTP meaning | Useful investigation |
|---|---|---|
| 400 | The request cannot be processed as submitted | Check documented input and request format. |
| 401 | Valid authentication is required | Check the expected authentication mechanism and credential configuration. |
| 403 | The server refuses the request | Review the response details and permitted access. |
| 404 | The requested resource was not found | Confirm the route; check whether this endpoint documents a special lookup meaning. |
| 405 | The request method is not supported for the target | Confirm the documented HTTP method. |
| 429 | Too many requests | Respect the provider's limits and retry guidance. |
| 502 or 503 | Gateway/server availability problem | Review service information and avoid aggressive retries. |
This table summarizes general HTTP concepts, not BreachDirectory's current status-code specification. Source: MDN HTTP status reference
An integration should not convert every non-success status into an empty result list. It should preserve an error or unknown state unless the provider explicitly documents that response as a completed negative lookup.
Developer Check 3: Handle Rate Limits and Temporary Failures
If a response includes Retry-After, honor the indicated waiting period. The header can express a delay in seconds or a date, depending on its value. Source: MDN Retry-After reference
Use bounded retries only for conditions where retrying makes sense. Authentication, validation, and permission problems usually require a corrected request or approved configuration rather than a loop.
For retryable temporary failures, use a limited backoff strategy and stop after a reasonable budget. Deduplicate accidental duplicate requests in your own application. Do not evade limits by cycling keys or sending parallel requests through other identities.
A 429 generally indicates rate limiting; it does not disclose the provider's exact quota by itself. Consult the current plan and documentation instead of guessing a universal request allowance. Source: MDN 429 reference
Developer Check 4: Recognize a CORS Problem
A request can behave differently in browser JavaScript and a server-side client because browsers enforce cross-origin access rules.
CORS uses server-provided headers to tell a browser which origins may read a response. Some requests also involve a preflight check. A CORS error therefore needs investigation of the browser request and server policy, not merely the submitted email address. Source: MDN CORS guide
Do not recommend disabling browser security as the solution. Setting a request to no-cors does not turn a restricted response into ordinary readable API data.
If the provider supports an authorized server-side integration, design it within those terms. Keep secrets server-side, validate your own application's inputs, and control access to the route. Do not create an open proxy or use a random public proxy to relay sensitive identifiers.
A server-side architecture is not permission to bypass a provider's access restrictions.
Developer Check 5: Validate the Response Before Showing a Result
A successful HTTP transport response is not enough to establish a meaningful breach result.
The Fetch API's response.ok indicates an HTTP status in the 200–299 range. It does not confirm that a response body matches your expected application schema. Source: MDN Response.ok reference
Check content type, parse errors, documented application-level errors, and expected result structure. A request might return HTML where your client expects JSON, or a schema might differ from the historical example used to build the integration.
Avoid defaulting a missing field to an empty array and immediately displaying “no exposure found.” A missing or unrecognized result can mean the response was not understood.
A clearer outcome model distinguishes matches, a documented completed no-match result, invalid input, access restrictions, temporary failures, and unknown responses. These are suggested application states, not an official BreachDirectory schema.
A Troubleshooting Note You Can Send to Support
Prepare a short private report with:
- The provider and feature involved.
- The approximate time and time zone.
- Whether the issue affects the website or your application.
- The status and a redacted error description, if available.
- Whether the failure is consistent or intermittent.
- Non-sensitive configuration details relevant to reproduction.
Do not include API keys, authorization headers, session cookies, passwords, unredacted breach records, or full lists of employee addresses.
If support requests a diagnostic export, inspect it for sensitive information before sharing. A browser network export can include more than the one failed request you intended to describe.
What If You Need an Answer Before the Service Works Again?
Use another documented exposure-checking service if it meets your needs and you are comfortable with its privacy practices. Record it as a separate source rather than pretending it completes the failed original query.
Different providers may return different information. A negative answer elsewhere does not retroactively turn the first failure into a successful search.
If you already know a password is exposed or reused, replace it through the account provider. If you see unfamiliar account access, investigate it through that provider's security process. Neither action requires waiting for a breach lookup to become available.
Final Thoughts
When BreachDirectory is not working for your task, identify the failure before choosing a fix. Confirm the provider, separate website issues from API integration problems, and keep failed requests distinct from completed negative results.
For developers, current endpoint documentation, careful response validation, honest error states, and protected diagnostic information matter more than repeated retries.
Explore our BreachDirectory learning hub for related explanations, and the BreachDirectory API guide for integration context.
Editorial scope: This article provides general troubleshooting guidance. It does not assert that BreachDirectory is currently down, confirm specific quotas or endpoints, or present a live test of its interface. HTTP and browser concepts are general unless a provider-specific source is identified. ACyberSec is not affiliated with BreachDirectory.
Related articles
