Privacy policy

qarunbook (qarunbook.com) is an app-testing runbook: teams write test plans, record results and raise issues against the apps they build. This page says what we keep to make that work. We do not sell data, show ads, or put analytics or tracking scripts in your browser.

What we store

• Your account: name, email address, and a salted hash of your password — never the password itself.
• Your workspace: its name, its members and their roles, and invitation or join links you create.
• What you put in: test plans, results, issues, their edit history, and files you attach to issues.
• An access token for each member, so an AI assistant you connect acts as you. You can replace it at any time.
• A usage record of actions (such as a result recorded), shown to your workspace on its Usage page.
• For a paid workspace: which plan it is on and its billing status. Stripe holds the payment details themselves.
• Where your account came from: the page you first landed on and the site that linked you there, sent with the sign-up form.
• If that page was a partner’s link (one ending in ?ref=), which partner. They are told how many accounts their link brought and what those workspaces paid — never who you are. The partner is credited even if your browser sends Do Not Track or Global Privacy Control, because following their link was your choice; nothing else about where you came from is kept in that case.

Cookies and browser storage

One cookie, qa_session, keeps you signed in. It is HttpOnly and sent only to qarunbook.com. Your browser also remembers your light/dark choice and whether you have signed in before, so the right screen shows while the page loads. On the public pages, the first page you open in a tab and the site that linked to it are kept in that tab’s session storage, so the sign-up form can say where you came from; it is gone when the tab closes. There are no advertising or third-party tracking cookies.

Visitors to the public pages

We count page views on the public pages — the home page, the guides, and these policies — so we know which pages are useful and roughly where readers are. It uses no cookies and no third-party analytics. For each view we keep the page, the site that linked to it, the country and city our host reports at the network edge, and whether the device is a phone, tablet or computer. If the page was opened from a partner’s link, we also keep that partner’s code, so they can be told roughly how many visits their links brought.

We do not store IP addresses. So that a reader who comes back is counted once rather than every time, the address is turned into a one-way code with a secret key only our server holds; the code is the same each time you visit, and the address cannot be worked back out of it. The code is tied to nothing else about you — not an account, a name or an email address. If your browser sends “Do Not Track” or Global Privacy Control, nothing is recorded at all. None of this runs inside the app once you are signed in.

Product analytics

To learn which channels bring people who find qarunbook useful, our server sends PostHog a short record when key things happen: an account or workspace is created, an app is created or imported, a result is recorded, an issue is raised or fixed, a teammate is invited, or a plan is bought. Each record carries your account’s internal id, your workspace’s id, which channel was used (web, AI assistant or API), and where your account first came from. It never carries your name, your email, or anything you wrote — not app names, check text or issue text. Nothing runs in your browser for this, and no cookie is set. Public page views are passed on with the same daily code described above, never tied to a person.

Google Ads

If you arrive from one of our Google ads, the link carries a click code from Google. If you then create an account, we tell Google Ads that this click led to a sign-up: the click code and the time, nothing else — never your name, email or anything you wrote. There is no Google tag or cookie on our pages. If your browser sends “Do Not Track” or Global Privacy Control, the click code is not kept.

Who processes it for us

• Vercel — hosts the website and the API.
• MongoDB Atlas — the database.
• Backblaze B2 — stores the screenshots, recordings and other files attached to issues, in a private bucket.
• Bunny.net (Bunny Stream) — receives a copy of each video attached to an issue, with its file name, so it can be played in the browser. Deleting the attachment deletes it there too.
• Anthropic — only when someone uses AI import. The file or text you give it is sent to Anthropic’s Claude so it can be turned into a test plan, along with the name and platforms of the app it is going into when that app already exists. Nothing is sent otherwise, and nothing else in your workspace is.
• Zoho ZeptoMail — sends account emails (verification, invitations, password resets, confirmation codes), billing notices, notices that an issue you raised was fixed or one was assigned to you, and reports you choose to email to someone, with the note you add.
• Resend — holds your name and email for occasional product news and a short series of welcome emails after you sign up, which you can turn off in your profile or with the unsubscribe link in any of them. It also sends a checklist you ask to have emailed from our templates. Deleting your account removes you from it.
• Cloudflare — DNS for the domain and forwarding of mail sent to our addresses.
• Google Fonts — serves the typeface the site uses.
• Stripe — processes payments for paid plans. We do not store your card number; Stripe does.
• PostHog — product analytics, as described above. Sent from our server only.
• Google Ads — the click code and sign-up time described above, for accounts that came from one of our ads.

Integrations you choose to connect

These only happen for apps or workspaces an admin connects on purpose, and stop when the connection is removed. Issues already sent stay in the other service, under that service’s own privacy policy. Tokens and keys you give us for them are stored encrypted.

• GitHub and GitLab — we read the pull or merge requests, deployments and issues of the repository you choose, to mark an issue fixed. If you turn on filing, or send an issue by hand, its code, text, check, platforms and a link back are created as an issue there. When a merged pull request names no code, its title, description, branch and changed file names are read by Anthropic’s Claude to suggest which issue it fixes.
• Linear and Jira — each issue raised in the app is filed in the team or project you choose: its text, the check’s steps and expected result, its platforms and priority, the app’s name and the name of whoever raised it. We receive back only the change of status that marks it done.
• Slack — when someone raises a bug from a message, we receive that message’s text and files, the channel, and the Slack user’s name and email (to match them to a member). The bot replies in that thread, and posts new and fixed issues to the channel an admin picks.
• Microsoft Teams — when someone raises a bug from a message or sends our bot “bug”, we receive that message’s text and the files Teams hands over, the team, channel or chat it was in, and the Teams user’s name and work email (to match them to a member). We remember where the bot has been added, so it can list channels and write to a reporter. The bot replies in that thread, writes to the reporter directly when it cannot, and posts new and fixed issues to the channel an admin picks.
• Sentry — for the project you connect, we receive the issues Sentry sends us, and read each one and its latest event from Sentry’s API. We keep the error’s title, where it happened, its level, platform, environment, release, first and last seen, how many events and people it has had (a count, never who they are) and its link, as the bug. We send back only a request to resolve an issue once its bug is fixed.
• Email — mail sent to an app’s private address passes through Cloudflare Email Routing to us. We keep the sender’s name and email, the subject, the body and the attachments as the issue, and email the sender when it is logged and when it is fixed. They can turn those replies off with the link in each one.
• Incoming webhook — a tool you point at an app’s webhook URL sends us whatever its payload holds. We keep the title, description, platforms, priority, the page it names, a reporter’s name and email if one is sent, and the tool’s own id and link, as the issue; the rest of the payload is not stored. If you give a notify URL, we send it the issue’s code, link, status and who fixed or verified it.
• PostHog — your own PostHog project, not the analytics we use. A destination you set up sends us the events you choose; we keep the error or event, its page, browser and device, the person’s PostHog id (and their email only if you turn that on) and links to the session replay as the issue. With your read-only key we look up a reporter’s latest session, by their PostHog id or email, when someone asks. Nothing is written to PostHog.
• Zapier — with an API key you create, Zapier reads and writes issues and results in your workspace for the Zaps you build, and passes them to the other apps in those Zaps.
• AI assistants (MCP) — an assistant you connect with your personal token, such as Claude Code, Cursor or Codex, can read and write the apps you can, as you. What it does with that data is governed by the assistant you use.

Who can see your work

Only members of your workspace, limited by the role and apps an owner gives them. No other workspace can see it.

Deleting your data

Owners can delete apps, and everything recorded against them, from inside the app. To remove your account or a whole workspace, write to [email protected] from the address on the account and we will delete it.

Changes

If this policy changes in a way that matters, we will update the date above and say so in the app.