Legal

Privacy policy

Last updated 24 August 2026

This describes exactly what QA Spider collects, why, where it is stored and who else can touch it. We have tried to write it in plain English rather than legal padding — if anything here is unclear, ask us and we will fix the wording.

1. Who we are

QA Spider ("we") provides automated software-testing services for web applications. This policy covers the QA Spider website and the QA Spider dashboard. For any privacy question, or to exercise a right described below, email hello@qaspider.com.

2. What we collect

We collect only what the service needs to function. Specifically:

  • Account data — your name, email address and a hashed password (we never store your password in readable form). If you sign in with Google or GitHub, we receive your name, email and avatar from that provider instead.
  • Workspace data — your organisation name, team members and their roles, and invitations you send.
  • Project configuration — the URLs of the applications you ask us to test, the environments you define, and any test-account credentials you choose to store so our tests can sign in.
  • Integration credentials — the API tokens or webhook URLs you provide to connect a bug tracker or a chat tool.
  • Test results — run outcomes, timings, per-step results, error output and screenshots captured from the pages we tested, plus any bug reports generated from them.
  • Usage and billing data — your plan, token balance and a ledger of consumption events (which run or generation used what).
  • Contact submissions — the name, email and message you send through our contact form.
  • Scan requests — if you ask us to scan your own site from our home page, the address you give us and the site you asked about, so we can send you the report and answer if you reply. See section 6.
  • Server logs — standard technical logs, including IP address and user agent, kept for security and debugging.
  • Website analytics — which pages are viewed and which links are clicked, so we can tell what people find useful. Where consent law applies this is measured without cookies and without any identifier, so each visit is counted on its own; elsewhere a cookie is set so a returning visit can be recognised. See section 11.

3. What we do not do

  • We do not sell your personal data, and we never have.
  • We do not build advertising profiles of you and do not use personalised advertising or remarketing. Where consent law does not require otherwise, we do measure whether an ad click led to a sign-up, so we can tell which advertising is worth paying for.
  • We do not put any analytics or tracking script on the audit reports we send to companies.
  • We do not use your application data or test results to train machine-learning models.
  • We do not read your source code unless you connect a repository yourself. If you do, access is read-only, limited to the repositories you select, revocable by you at any time on GitHub, and we never store your code — files are read for the moment of a question and discarded.

4. Why we process it

To provide the service you signed up for (running tests, reporting results, filing bugs to your tracker, sending alerts) — this is performance of a contract. To secure accounts, prevent abuse and debug failures — our legitimate interest. To send you the transactional emails the service depends on, such as sign-in codes and run notifications — performance of a contract. Where we ever rely on consent, such as optional marketing email, you can withdraw it at any time.

5. Test-account credentials — please read

If you store credentials so our tests can sign in to your application, use a dedicated test account with the minimum permissions needed, on a non-production environment wherever possible. Never store a real customer or administrator account.

Integration tokens and test-account credentials are both encrypted at rest with AES-256-GCM. If our server cannot encrypt them, it refuses to store them rather than keeping them in readable form. Even so, treat any credential you give us as one you would be comfortable rotating, and rotate it if you stop using QA Spider.

6. Audit reports — the ones you ask for, and the ones we send unasked

There are two ways one of our reports comes to exist, and they are not the same thing.

If you asked for it: you gave us a URL and an email address on our home page, we read that site and sent you the report. We hold your address to send it, to let you ask us about it, and to delete it on request. We do not add you to a mailing list, and we send nothing else unless you write to us first. Reports requested this way are read at a shallow depth by default; a deeper pass runs only if you press the button in the report asking for one.

If you did not ask for it: we sometimes read the publicly reachable pages of a company we would like to work with, and send that company a report of what we found. We do this before any relationship exists, so it is worth stating plainly what it involves.

What we read is what anyone with a browser can read: pages linked from your sitemap, fetched once each, respecting robots.txt, with no load placed on your systems. We do not sign in unless you give us a test account, and if you do, the pass reads pages and submits no form other than the login. The report is served from an unlisted link, is excluded from search engines, and can be withdrawn on request.

Each report link records when it is opened, along with the IP address, the city and country derived from it, and the browser. For a report we sent unasked, we use this to judge whether it was read and whether it was forwarded, which is the only way to know whether a follow-up is welcome; that processing rests on our legitimate interest in business-to-business outreach. For a report you asked for, the same record exists but does us no such favour — it is there because the link is public to anyone holding it, and we would want to know if one were being passed around. Addresses and browser details are deleted after 90 days, after which only a count of opens remains.

If you would rather we did not hold any of this, email hello@qaspider.com and we will delete the report, the link and its open records. We will also stop contacting you, and we do not need a reason.

7. Where your data lives, and who else touches it

The application and its database are hosted on Render, in the EU (Frankfurt) region, on an encrypted persistent disk. We use a small set of subprocessors, each for one clearly-bounded purpose:

  • Render — application hosting and database storage (EU).
  • Anthropic — the AI model that drafts test cases, QA documents and bug reports. It receives the prompt and the product context needed for that artifact.
  • Resend — delivery of transactional email (sign-in codes, notifications, contact replies).
  • GitHub Actions — executes your test runs and reports the result back to us.
  • Firecrawl — fetches and maps the public pages of a site you ask us to analyse.
  • Browserbase — provides the hosted browser used for optional live test recording. Only used if that feature is enabled for your workspace.
  • Umami — counts visits to our website. Sets no cookie and stores nothing on your device; uniqueness comes from a hash computed on its servers from a salt that changes daily.
  • Google Analytics — measures visits to our website and dashboard. IP addresses are truncated. Storage is disabled where consent law applies and enabled elsewhere.
  • PostHog — product analytics and, only with your agreement, session replay of our own website. Runs without storage until you agree.
  • GitHub — if you connect a repository, we read the files needed to answer a question about a failing test. Read-only, and nothing is stored by us.
  • Google and GitHub — identity providers, only if you choose to sign in with them.

8. How long we keep it

Account and workspace data are kept while your account exists. Test results, screenshots and generated bug reports are kept so your history and metrics remain meaningful; you can delete individual runs, bugs and projects at any time, and deletion is immediate. Contact-form messages are kept while we need them to answer you. Server logs are retained for a short operational period. When you close your account we delete your workspace data, retaining only what we must for legal or accounting reasons.

9. Your rights

You can access, correct, export or delete your data. Much of this is self-service in the dashboard: you can export generated documents, delete bugs, runs and projects, and manage team members. For anything else — a full export, account deletion, an objection to processing, or a complaint — email hello@qaspider.com and we will respond within 30 days. If you are in the EEA or UK you also have the right to lodge a complaint with your local data-protection authority.

10. Security

Access to the production environment is restricted to the people who operate it. Traffic is served over HTTPS. Integration tokens are encrypted at rest. Outward-facing actions — filing a ticket in your tracker, posting to your chat, running against a production-looking environment — require explicit approval in the product rather than happening silently. No system is perfectly secure; if we become aware of a breach affecting your data we will notify you without undue delay.

11. Cookies

The only cookie we set is strictly necessary and exists because the site cannot work without it: a session cookie that keeps you signed in. Your light or dark theme preference is stored in your browser's local storage rather than a cookie, so it never travels to us.

What our analytics stores depends on where you are. Where consent law applies — the EU, the EEA, the UK and Switzerland — Google Analytics and PostHog run with storage disabled: we count that a visit happened and which pages were read, nothing is written to your device, and nothing connects this visit to your next one. Elsewhere they set a cookie, which lets us recognise a returning visit and tell whether an ad click led to a sign-up.

Umami, which is our main counter, sets no cookie anywhere and needs no permission. That is why the site does not put a cookie wall in front of you.

Session replay of our own website — a recording of how the page behaved for you — is only ever switched on if you agree to it when asked, and refusing costs you nothing: you are still counted.

We do not use personalised advertising or remarketing, and we do not build profiles of visitors.

12. Children

QA Spider is a business tool and is not directed at anyone under 16. We do not knowingly collect their data.

13. Changes

If we change this policy materially we will update the date above and, for changes that affect how we handle your data, notify account owners by email before the change takes effect.

Questions about this policy, or a request about your data? Email hello@qaspider.com.