bugscreen
Last updated · 7 August 2026

Privacy Policy

This Privacy Policy explains how BugScreen Limited ("we", "us") collects, uses, and shares personal data in connection with BugScreen, the bug-reporting platform available at bugscreen.app and through our client SDKs (the "Service"). It applies to people who hold a BugScreen account ("Customers") and to the testers a Customer permits to exercise a build and submit reports via its integration ("Authorised Testers").

1. Our role

For Customer account data (the records identifying an organisation, its members, and its subscription), we act as a controller. For bug reports submitted through a Customer's SDK, the Customer is the controller of the personal data it contains and we act as a processor on its behalf. Authorised Testers with questions about a specific bug report should contact the Customer whose build they were testing.

Our processor activities — including the subject matter, duration, nature, and purpose of processing, the categories of data and data subjects, our security commitments, sub-processor terms, and assistance with data-subject requests — are governed by our Data Processing Addendum (DPA), which is published at bugscreen.app/dpa and incorporated into our Terms of Service by reference. It takes effect when a Customer accepts those Terms and needs no separate signature.

2. Data we collect

Customer account data

  • Account and membership records — your email address, your organisation's name, and your role and membership status within it;
  • Subscription records — the identifiers our payment processor issues for your organisation and its subscription, the plan you are on, your billing interval, the current billing period, and whether a cancellation is scheduled;
  • Your name and authentication credentials (password, multi-factor enrolment) are held by our identity provider (see "Sub-processors"), not by us. We read your name from them when the console needs to display it; we do not keep a copy;
  • Operational and diagnostic logs generated when the console and our API handle your requests, which may incidentally include IP address, user agent, and timestamps.

In-console product feedback

If you send us free-text feedback through the in-console help & feedback button, it travels through the same reporting pipeline as an SDK bug report — so, as described below, we do not store it either. It is forwarded to our own issue tracker and discarded on our side. Alongside your message we send your account identifier, the console URL you submitted from, your browser user agent and viewport size, the time of submission, and a marker identifying the feedback button as the source.

SDK-collected bug reports

When an Authorised Tester submits a report through one of our SDKs, the SDK transmits to our backend:

  • up to four screenshots the Authorised Tester chose to attach;
  • the free-text description the Authorised Tester wrote;
  • a reporter-selected bug type (e.g. Bug, UI, Crash) and severity (e.g. Low, Medium, High), used to label or prioritise the issue created in the Customer's connected tracker;
  • a log file, attached automatically whenever the SDK has log messages buffered. Unlike the screenshots, it is not chosen or previewed by the Authorised Tester before sending. It contains only the messages the Customer's own application code passed to the SDK's logging API — the SDKs do not read the device's system logs — and the buffer is size-capped, so only the most recent messages are kept. What ends up in it is therefore under the Customer's control;
  • device, app, and display characteristics collected automatically: device and operating-system details (such as model, OS version, and total and available memory), application details (such as app version, build number, package or bundle identifier, and BugScreen SDK version), display details (such as screen size, pixel density, and whether the app is rendering in dark or light mode), and the device locale. None of these identify a particular device or person;
  • optional custom key/value pairs that the Customer has configured in its host app via the SDK's setCustomData API (e.g. environment, build type, or user-tier labels), including an optional account identity the Customer may attach via the setUser API — an account identifier, a role, and an email address. Where a report carries an email address, it is because the Customer's application supplied it: the report form has no email field, and the Authorised Tester is not asked for one. The SDK does not collect this data itself, it transmits whatever the Customer supplies, and it is for the Customer to have a basis for sharing it.

Each request is authenticated with the Customer's SDK key, sent as a credential in the request header rather than as part of the report.

The SDKs do not collect contact lists, precise location, microphone, or camera data beyond the screenshots the Authorised Tester has explicitly chosen to attach. Screenshots may incidentally contain personal data that is on-screen at the moment of capture; Customers are responsible for warning their Authorised Testers about this, and about the log file their application populates.

We do not keep the report itself. The description, the bug type and severity, the device metadata, any optional email address, and any custom data the Customer attached are used to create the issue, task, or message in the Customer's connected Integrations and are then discarded — they are never written to a database on our side. The only part of a report we store is its screenshot and log attachments, and only for the fixed window described under "Retention" below. Once a report has been forwarded, the Customer's tracker holds the record; we do not.

Integration tokens

When a Customer connects a GitHub, Jira/Atlassian, ClickUp, Slack, or Linear integration, we store the OAuth access and (where issued) refresh tokens needed to create issues or tasks, or post messages, on the Customer's behalf. Tokens are stored encrypted at rest and used only to perform actions the Customer has authorised.

Cookies and analytics

The cookies the console and our API set are first-party and necessary for the site to work, and fall into one of three purposes: keeping you signed in (a session cookie issued by our identity provider); completing a sign-in or integration-connection handshake securely (short-lived cookies that protect the exchange against interception and cross-site request forgery, discarded once the handshake finishes); and remembering small interface preferences such as your last-used sort order. We also keep a minimal signed-in hint in your browser's local storage so the site knows whether to send you to the app or to the marketing pages. None of these require your consent.

With your consent, we also set advertising cookies. Google Ads sets a first-party cookie to measure whether a visit that began with one of our advertisements resulted in a sign-up or a subscription, across our public pages and the signed-in application. No advertising cookie is set, and no data is sent to Google, unless you accept.

You may decline, and you may withdraw your consent at any time from the Cookie preferences control on our public pages. Declining restricts no part of the Service. The Google advertising cookie carries no email address, no name, and no account, organisation, or workspace identifier, and we do not use it to build a profile of you.

Each time a workspace is created, we send LinkedIn a one-way code derived from the sign-up email address, to measure sign-ups originating from one of our advertisements. We send no name, no organisation or workspace identifier, and no part of any bug report. We cannot reverse the code back into the address, but LinkedIn may be able to match it to a LinkedIn member.

The console loads Vercel Web Analytics, a privacy-focused, cookieless analytics script provided by our hosting provider, to measure aggregate traffic (page views, country-level location, referrers, device class). We also record a small number of aggregate interaction events — which sign-up button was pressed and which plan it referred to, which app-store link was followed and from where, which setup step was reached and whether it was completed, whether an app is still waiting for its first bug report, which installation snippet was copied, which issue tracker a connection was started for, and when companion-app pairing was started — to measure which parts of the site are used and where people stop during setup. These events carry no information that identifies you. It does not set tracking cookies and does not build cross-site profiles. See "Sub-processors" below. It requires no consent and is not covered by the choice above.

Our public pages and the console also load PostHog, a product-analytics service provided by PostHog, Inc. and processed in the European Union, to measure which pages are visited, which controls are used, and where people leave the sign-up and setup path. It records page views and the same interaction events, together with the browser, operating system, device type, screen size, and referring site. The address of each page is reduced before it is sent, so these events carry no account, organisation, or workspace identifier, no email address, and no name, and your IP address is not stored with them. Nothing is stored on or read from your device, so this needs no consent and the choice above does not affect it; we rely on our legitimate interest in measuring how the Service is used. Visitors are counted by an identifier PostHog computes on its own servers, and your browsing is not associated with your BugScreen account. We also record from our own servers when a sign-up is started and which plan it referred to; that record carries no identifier and is linked to no account.

We also record what your account does in the Service — the setup steps it completes, the integrations it connects, the reports it receives, and changes to its plan and that plan's price — and send those records to PostHog. They are linked to the internal identifiers we hold for your account and your organisation, and carry no email address, no personal or organisation name, and no part of any bug report. Nothing is stored on or read from your device, and the choice above does not affect them. We rely on our legitimate interest in analysing how the Service is used.

The BugScreen companion app uses Firebase Crashlytics and Google Analytics for Firebase to report its own crashes and to measure how the app is used. The events record which of the app's screens you saw, which steps were reached and whether they succeeded, and which of the app's links out to this website you opened — never anything you typed. The Firebase libraries assign a persistent identifier to each installation of the app, so these events are not anonymous.

What the companion app never sends to Firebase: your name, the title or description of any bug report, any screenshot or image, the join code you paired with, and the credential the app holds for your device. We do not set a user identifier, we do not collect an advertising identifier, and we do not use any of this for advertising or tracking.

3. How we use the data

  • to provide the Service: ingesting bug reports, storing screenshots, and forwarding issues to the Integrations a Customer has configured;
  • to operate Customer accounts: authentication and support;
  • to keep the Service secure: rate limiting, abuse detection, operational logging;
  • to improve the Service: analysing how the Service is used, and analysing Customer Data in aggregated and de-identified form only;
  • to measure which advertisements lead to sign-ups;
  • to comply with legal obligations.

4. Legal bases (GDPR/UK GDPR)

For Customer account data we rely on:

  • Contract — to provide the Service you signed up for;
  • Legitimate interests — to secure the Service, prevent abuse, improve it, and measure the effectiveness of our advertising, balanced against your rights;
  • Legal obligation — to meet tax, accounting, and other regulatory requirements;
  • Consent — where we ask for it, e.g. for optional marketing.

For SDK-collected bug reports, the Customer chooses the legal basis applicable to its Authorised Testers; we process on the Customer's documented instructions as set out in our terms.

Providing your account data is a contractual requirement: without an email address and an organisation name we cannot create an account or provide the Service. We do not take decisions about you by solely automated means that produce legal effects concerning you or similarly significantly affect you, and we do not use your personal data to build marketing or advertising profiles or to define advertising audiences.

5. Where data is stored

The Service runs on Amazon Web Services. Customer Data is held in AWS DynamoDB tables (account records, organisation configuration, integration metadata, and per-organisation usage counters) and AWS S3 (screenshot and log uploads). There is no bug-report table: as described above, report content is forwarded to the Customer's Integrations rather than stored. Data is processed in the AWS eu-west-2 (London) region. If we add additional regions, we will update this policy and the sub-processor list before doing so.

6. Sub-processors

We engage sub-processors in the following categories to deliver the Service: backend hosting, database, and attachment storage; identity and account management; console hosting and cookieless web analytics; product analytics; advertising measurement, where you have consented to it; subscription billing; and the issue trackers and messaging tools a Customer chooses to connect as Integrations. That last category is customer-initiated — those providers receive personal data only once a Customer connects them, and only for the reports that Customer forwards.

Card details are entered directly into our payment processor's own hosted pages and are held by it; we never receive or store card numbers.

The definitive list of named sub-processors is published at bugscreen.app/subprocessors — including the service each performs and the location of processing — and is kept up to date as our supplier mix changes. We will update that page before engaging a new sub-processor that will process personal data on behalf of Customers.

7. Sharing

We share personal data only:

  • with the sub-processors above, under written contracts;
  • with the Integrations a Customer has connected (issues, attachments);
  • with our professional advisers (legal, accounting), under a duty of confidence;
  • where required by law, court order, or to protect rights and safety;
  • in connection with a corporate transaction (merger, acquisition, asset sale), in which case we will require the recipient to honour this policy.

We do not sell personal data.

8. International transfers

Some of the providers listed in the sub-processor section above may process data outside the UK and EEA, including in the United States. Where that happens, we rely on appropriate safeguards — typically the UK International Data Transfer Addendum or the EU Standard Contractual Clauses, together with any supplementary measures required — to keep the level of protection consistent with UK/EU law.

9. Retention

We do not retain report content (see "Data we collect"). The copy created in a third-party Integration (such as GitHub, Jira, ClickUp, Slack, or Linear) is the durable record of a bug report, held in that third party's system under the Customer's control. We have no facility to remove it on a Customer's behalf: the Customer must delete the corresponding issue, task, or message in each Integration directly. Authorised Testers who wish to have a report removed should contact the Customer.

  • Bug report content (description, metadata, bug type and severity, any optional email or custom data) is not retained at all. It is forwarded to the Customer's Integrations at the moment of submission and not stored on our systems.
  • Screenshot and log attachments are deleted automatically 30 days after upload. This happens unconditionally and does not depend on the organisation remaining active. We do not offer a way to delete an attachment sooner.
  • Customer account data is retained while the account is active. Deletion is handled manually on request rather than by an automated timer — we act on requests as soon as we can, but we do not currently operate an automatic deletion schedule and so do not commit to a fixed window. To request deletion, email [email protected] or use the delete-account option in your settings, which opens the same request.
  • Database backups. The tables holding the account, organisation, integration-configuration, and usage records described above have point-in-time recovery enabled, which allows restoration to any point within a rolling 35-day window. Short-lived tables that hold data only for the duration of a single operation are excluded, as are screenshot and log attachments — those are not separately backed up, and the 30-day expiry above is final for them.
  • Operational and diagnostic logs — the application logs generated when the console and our API handle requests — are retained for 12 months and then deleted automatically.
  • Companion app usage events — the app-activity events described under "Cookies and analytics" — are retained by Google for 2 months, the shortest period the analytics service offers, which we have selected. Crash reports from the companion app are retained by Google on the crash reporting service's own schedule; that period is not a setting we control.
  • Product analytics events — the page views, interaction events and account activity records described under "Cookies and analytics" — are retained by PostHog for the period our plan with it sets; we do not configure a shorter one.
  • Advertising measurement — collected only with your consent, as described under "Cookies and analytics". The cookie in your browser and Google's records of an advertisement click expire on Google's own schedule; neither period is a setting we control. Withdrawing your consent stops further collection and deletes the advertising cookies held under our own domain.
  • Sign-up conversion measurement — the one-way code sent to LinkedIn when a workspace is created, as described under "Cookies and analytics". We retain no copy. LinkedIn keeps its record on its own schedule; that period is not a setting we control.
  • Infrastructure audit logs are retained for up to 3 years. These are separate from the application logs above: they record administrative actions taken against our cloud infrastructure by our own operators, so that we can investigate a security incident discovered long after the fact. They capture activity in our cloud provider's management interfaces rather than the content of Customer Data.

10. Your rights

Depending on where you live, you may have the right to access, correct, delete, port, or restrict the processing of your personal data, and to object to processing based on legitimate interests. You can also withdraw consent at any time without affecting prior processing.

Authorised Testers: if you filed a bug report from a build you were testing, please contact the organisation whose build it was; they are the controller of your report. The durable record of your report lives in that organisation's own issue tracker. Any screenshots or logs you attached are also held by us, but only until they expire 30 days after upload.

Customers: you can exercise your rights by signing into the console or by emailing [email protected]. You also have the right to lodge a complaint with a supervisory authority — in the UK, the Information Commissioner's Office (ico.org.uk).

11. Security

We protect personal data with technical and organisational measures appropriate to the risk, including TLS in transit, encryption at rest, hashed SDK keys, envelope-encrypted integration tokens, least-privilege access to production systems, and access logging. Account credentials are held by our identity provider, not by us. No system is perfectly secure; if we become aware of a breach affecting your personal data we will notify you and the relevant authorities as required by law.

12. Children

The Service is not directed at children under 16 and we do not knowingly collect personal data from them. If you believe a child has provided us with personal data, please contact us so we can delete it.

13. Changes to this policy

We may update this policy as our practices change. If we make a material change, we will give reasonable notice via the console or by email. The "Last updated" date at the top of this page indicates when it was most recently revised.

14. Contact

BugScreen Limited is the controller for Customer account data and is the point of contact for all questions about this policy: [email protected]. See also our Terms of Service.

BugScreen Limited is a private limited company registered in England and Wales, company number 17247095, with its registered office at Friarsfield, Glaisdale, Whitby, England, YO21 2PS.

    Privacy Policy | BugScreen