EU-hosted Playwright reporting and GDPR

Personal data in test results

A test result looks technical, but it can name people and show their data:

• Commits. The commit message and the author's name come with every run.
• Test accounts. Names and email addresses in test data end up in error messages, in the page snapshot and in the test output.
• Screenshots and traces. A screenshot shows whatever the page showed. A trace also holds the page at each action, the network requests and the console.
• URLs. An address in an error message can carry a token or a session ID.

When an organization sends its test results to Squally, the organization is the controller, and Squally processes the test data on its behalf as a processor (Art. 28 GDPR), under a Data Processing Agreement. Account data - your name, email address and sign-in - is outside that agreement: for it, Squally is a controller itself.

This guide is not legal advice. The binding texts are the privacy policy and the Data Processing Agreement; which rules apply to your tests and your test data is for your organization to decide.

Where Squally stores what

Squally stores test data and account data in the EU. The app and its database run in Frankfurt, Germany; screenshots, traces and browser consoles are kept in file storage in the EU.

The error monitoring records Squally's own application errors; request bodies, cookies and authorization headers are removed before an error is sent.

Two points go beyond these locations. The weekly report email - with test names, file paths, error headlines, counts and the branch - is sent through Resend, which stores data in the USA and sends from the EU region (Ireland). And the providers behind the EU locations are US companies: Vercel, Neon and Cloudflare, with transfers based on the EU-U.S. Data Privacy Framework.

Sub-processors and DPA

Squally's Data Processing Agreement is concluded when an organization accepts the Beta Terms. A signed PDF copy is available on request from support@squally.dev.

Annex 2 of the DPA lists the sub-processors with their purpose and location, and the safeguard for each transfer:

• Vercel - hosting of the app and API, Frankfurt, Germany; EU-U.S. Data Privacy Framework
• Neon - the database, Frankfurt, Germany; EU-U.S. Data Privacy Framework
• Cloudflare R2 - screenshots, traces and console output, EU jurisdiction; EU-U.S. Data Privacy Framework
• Sentry - error monitoring, Germany; EU-U.S. Data Privacy Framework
• Resend - sending emails, data stored in the USA, emails sent from Ireland; Standard Contractual Clauses and EU-U.S. Data Privacy Framework
• IONOS - the support@squally.dev mailbox, Germany; within the EU

Before adding or replacing a sub-processor, Squally informs the organization by email at least 30 days ahead, and the organization may object.

Integrations an organization switches on itself - the GitHub App, a Slack webhook, the Playwright Trace Viewer - are not sub-processors: they are destinations it chooses. The same holds for the read API and the MCP server: whoever holds a read key of the organization can retrieve its test data, without console output, screenshots or traces.

The full list, including the providers for the website and for accounts: Sub-processors in the privacy policy.

What the reporter sends and doesn't

squally-reporter sends, for each run, the branch, the commit SHA, the commit message and the author's name, CI details, the Playwright version and selected fields of the Playwright config. For each test result: its name and file path, status and duration, error messages, stacks and code snippets, the page snapshot Playwright records at a failure, and the test output.

Screenshots, traces and the browser console are uploaded for attempts that failed or were retried, never for a test that passed on its first try. Such an attempt also sends its steps - the titles of actions, checks, hooks and fixtures - with typed values removed: a fill reads Fill "•••".

Not sent: your repository's contents, your test files beyond the snippet lines in an error, your environment variables beyond the CI values, and the commit author's email address. The base URL of your app is not sent unless you turn it on.

If you connect GitHub, Squally's GitHub App reads repository metadata and writes checks and pull-request comments. It has no access to your code.

Every field, with its limits: What the reporter sends in the docs.

Masking, and what isn't masked

Before upload, the reporter replaces secrets in common formats with [redacted], and Squally applies the same rules again when results arrive: Bearer and Basic authorization values, keys starting with sk_, GitHub tokens, Squally keys, AWS access key IDs and the password in a scheme://user:password@host URL. This covers error messages, stacks and snippets, the page snapshot, the test output, the commit message, step titles, annotations and the browser console.

Not masked: screenshots and traces - Squally stores them as Playwright wrote them. Names, file paths and branches are sent as they are, and a secret in any other format, such as password=… in plain text, is not recognised.

Masking catches known secret formats. It does not look for personal data: a customer's name in a screenshot or an email address in an error message stays as it is.

Retention

Squally deletes runs after a period that depends on the organization's plan, at most 90 days, together with their results, errors and steps. Screenshots, traces and browser consoles go earlier, on every plan: after 7 days for attempts that passed on their first try and after 21 days for failures and retried tests.

Deletion runs once a day. Database backups for point-in-time recovery expire within 1 day, and Sentry deletes error events after 30 days.

Every period, including the logs and support requests: Retention in the docs.

Sending less

The least data is the data you never send. Most of it is in your hands:

• Record fewer files in playwright.config.ts: screenshot: "off", trace: "off" or trace: "on-first-retry". Without a trace, Squally receives no browser console either.
• Use invented test accounts - made-up names and addresses at example.com - rather than copies of real customers.
• Keep secrets and personal data out of the test output and error messages: log an ID, not an email address. Masking catches the formats above, nothing else.
• SQUALLY_SEND_REPOSITORY=false keeps the repository's name out; the base URL is sent only with SQUALLY_SEND_BASE_URL=true.
• Special categories of personal data (Art. 9 GDPR), such as health data, must not be sent at all - the DPA says so.

use: {
  screenshot: "off",
  trace: "on-first-retry",
},

No screenshots, and a trace only when a test is retried.

Test use options lists the modes for screenshots, traces and videos.

Deleting data

The owner of an organization can delete it under Settings → Organization → Danger zone. It is locked at once and deleted for good 30 days later, with its projects, runs, artifacts and members, unless the owner restores it before then. A request to support@squally.dev works as well.

Projects can be deleted in the app too. On the Standard and Pro plans, runs and test results can be exported through the read API before the organization is deleted, and on request Squally confirms a deletion in text form.

Each person can delete their own account under Account settings → Danger zone → Delete account. While they own an organization, they transfer its ownership or delete the organization first.

More on the setup: Hosting and data in the docs. How other tools handle hosting: Compare. For the test results themselves: How to detect flaky tests in Playwright.