Data Handling

This document details what data Spekra collects, how we process it, where it's stored, and how long we retain it.

Data Collection

What We Collect

When you run tests with the Spekra reporter, we collect:

Field	Example	Purpose
Test file path	tests/auth.spec.ts	Identify and track tests
Test name	should login successfully	Display in dashboard
Suite hierarchy	['Auth', 'Login']	Organize test results
Status	passed, failed, flaky	Track test health
Duration	1234ms	Performance monitoring
Retry count	0, 1, 2	Flaky test detection
Error message	Expected 200, got 404	Debug failures
Playwright traces	.zip trace files	Debug with full context
Tags	['@smoke', '@P0']	Filtering and organization
Git branch	main, feature/xyz	Context and filtering
Git commit SHA	a1b2c3d4	Link to code changes
CI job URL	github.com/...	Link to CI runs

Playwright Traces

For Playwright tests, we upload the full trace file when available. Traces may contain:

Screenshots at each action
DOM snapshots
Network request/response data
Console logs

Sensitive data in traces

Trace files are uploaded as-is. Redaction (see below) applies to error messages and console output, but not to trace file contents like screenshots or DOM snapshots. Ensure your test environment uses sanitized or synthetic data.

Redaction

Redaction happens client-side before any data leaves your CI environment. This protects against accidental PII/secret exposure in error messages and console output.

Default Patterns

By default, redaction is enabled and filters:

Email addresses
JWT and Bearer tokens
API keys (common formats like sk_, pk_, api_)
Credit card numbers
US Social Security Numbers
Phone numbers
AWS access keys (AKIA...)
GitHub tokens (ghp_, gho_, etc.)
URL credentials (:password@)

Matched content is replaced with [REDACTED].

Adding Custom Patterns

Add patterns to extend the built-in list:

['@spekra/playwright', {
  apiKey: process.env.SPEKRA_API_KEY,
  redact: [
    'internal-secret',           // Exact string match
    /company-token-[A-Z0-9]+/i,  // Regex pattern
  ],
}]

Full Redaction Configuration

For complete control:

['@spekra/playwright', {
  apiKey: process.env.SPEKRA_API_KEY,
  redact: {
    enabled: true,
    patterns: [
      'my-custom-secret',
      /internal-api-key-\w+/gi,
    ],
    replaceBuiltIn: false,  // Set to true to ONLY use your patterns
  },
}]

Disabling Redaction

Not recommended, but you can disable redaction entirely:

['@spekra/playwright', {
  apiKey: process.env.SPEKRA_API_KEY,
  redact: false,  // ⚠️ Not recommended
}]

Redaction scope

Redaction applies to error messages and console output (stdout/stderr). It does not apply to trace file contents. For sensitive data in traces, use synthetic test data.

What We Do NOT Collect

We explicitly do not collect:

Source code - Your test code never leaves your environment
Environment variables - Never transmitted (except API key)
Secrets or credentials - Never collected or stored
Personal data - No user data from your application (unless present in traces)

Verify what's sent

Enable debug mode to see exactly what data is sent to Spekra:

['@spekra/playwright', { debug: true }]

Data Processing

Data Aggregation

We aggregate data to calculate metrics:

Reliability - Consistency of test results
Stability - Pass rate over time
Flakiness - Detection of inconsistent tests

Aggregated data is computed daily and stored separately from raw results.

Data Storage

Location

Data is stored via Supabase (hosted on AWS).

Encryption

In transit: TLS encryption on all connections
At rest: Supabase encrypts stored data
API keys: Hashed, never stored in plain text

Database Security

Row-level security (RLS) policies
Parameterized queries (no SQL injection)
No direct database access from internet

Third-Party Services

We use the following services:

Supabase: Database and storage hosting
Vercel: Web app hosting
Sentry: Error monitoring (application errors only)