# Fairlead, public documentation and product corpus

Private and draft content is excluded. Publication status and product limitations are stated per page. This is documentation, not an API for recording or retrieving sessions.

# Fairlead Recorder: Stop describing the bug. Hand over the evidence.

Canonical: https://fairleadhq.com/

Updated: 2026-09-26
Publication state: published
Product version: 0.1.0

Agent summary: Fairlead Recorder captures short browser checks for local review and downloads. Connected projects add shared configuration, backend correlation, issue submission and report storage.

## Prerequisites

- Google Chrome on a computer
- Permission to test the target application

## Inputs

- A user-controlled manual browser test session

## Outputs

- Reviewed browser evidence files
- Connected issue or report submission when configured

## Limitations

- Timeline retention is bounded; see Capture support and limits.
- Screenshots, console messages and notes need manual privacy review; Recorder has no pixel-redaction editor.
- Generated scripts need setup, safe test data and assertions. Recorder does not assess test outcomes.
- Backend correlation requires connected recording and an application that logs the identifiers. Header injection is not limited by capture domain rules.
- Downloads include session.md and notes.md when saved annotations exist. The downloadable sample is a real reproduction archive; its files reflect that recording.

## Permissions

- Active-tab access for the page being recorded
- Browser debugging access while recording network and console activity

## Privacy

- Inspect captured content before downloading or sharing; automatic redaction does not cover everything.
- Account-free recording does not send correlation headers or upload reports. Connected services and request headers have separate data destinations.
- Website analytics follows regional consent and your saved cookie preference. Local development runs no analytics.


Fairlead Recorder is a Chrome extension for recording browser tests, reviewing diagnostic evidence, and sharing selected files or submitting evidence through a connected project.

Record a short check and download the actions, requests and console messages behind it, ready to attach to any ticket.

Page title: Fairlead Recorder | Browser testing evidence for QA and developers
Updated: 2026-09-26
Publication state: published
Product version: 0.1.0

## Free. Forever.

The extension, capture, review, and bundle have no trial, seat, payment card, or session cap.

## Record locally. Choose how to share.

Account-free recording keeps evidence in your browser until you download it. Connected projects can submit issues and store reports in configured services.

Review each destination and the content you send. Connected recordings also add request identifiers during capture, including to third-party request destinations.

- **Local review:** Inspect actions, requests, console messages and attachments in the browser.
- **No account for local capture:** Record, review and download files without signing in. Sign in before starting a project recording.
- **Explicit start and stop:** Capture begins after Start. Stop preserves the retained timeline for review.
- **Review before sharing:** Inspect images and text yourself. Automatic rules do not remove every sensitive value.

1. **Start** — Begin just before the check you want to preserve.
2. **Record** — Capture browser actions, requests and console evidence.
3. **Review** — Inspect the result and sensitive content in the viewer.
4. **Download** — Save selected evidence for your issue or test run.

## Download the evidence your team needs.

- `network.har` — Captured HTTP requests and available responses in HAR format.
- `console.log` — Captured console messages and stack traces.
- `steps.json` — Supported actions in Chrome DevTools Recorder format.
- `playwright.spec.ts` — A starter Playwright test to adapt and add assertions to.
- `puppeteer.js` — A starter Puppeteer script to adapt before running.
- `screenshots/` — Added image attachments. Pixels are not automatically masked.

## Review captured data before sharing.

- Inspect captured content before downloading or sharing; automatic redaction does not cover everything.
- Account-free recording does not send correlation headers or upload reports. Connected services and request headers have separate data destinations.
- Website analytics follows regional consent and your saved cookie preference. Local development runs no analytics.

## Compare the Recorder with screenshots, video, and hosted capture tools.

This compares approaches rather than named products. The differences describe where the artifact lives and what a developer receives.

| Criterion | Screenshot + sentence | Screen recording | Hosted capture tool | Recorder |
| --- | --- | --- | --- | --- |
| Developer receives | The end state, in prose | A video of the interaction | A link to a session on the vendor's site | HAR, console, action flow, starter scripts and added images |
| Session lives | Your tracker | A local file or video host | Vendor servers under vendor retention rules | Your browser and downloads; optional project storage |
| Account required | No | Depends on the recording tool | Yes | No for local capture; yes for connected projects |
| Restricted network | Works | Local files work offline; hosted sharing needs access | Needs the vendor host | Local capture and downloads without a project connection |
| Primary cost | A second reporting round trip | Time spent reviewing video | A seat or retention plan | No Fairlead fee |

## Recorder technical FAQ.

### How does the Recorder protect sensitive tokens and personal data?

Automatic rules handle selected keys and structured content. Project rules replace the local baseline. Inspect console messages, notes, screenshots and unparsed bodies yourself; Recorder has no arbitrary field or pixel editor.

### Where is captured session data stored?

Local recordings remain in browser storage until downloaded. Connected projects can send issues and screenshots through Bridge and reports to their Data Plane. Correlation headers leave during connected recording, before submission.

### How does the Recorder differ from hosted capture tools?

You can record, review and download files without an account. Sign in before recording to use shared project settings and configured issue or report destinations.

### What formats are included in a Recorder bundle?

Downloads write individual files into a folder: network.har, console.log, steps.json, Playwright and Puppeteer scripts, and available screenshot PNGs. Downloads include session.md and notes.md when saved annotations exist. The website sample ZIP contains a real reproduction with its recorded artifacts.

## Recorder limitations and non-goals.

- Timeline retention is bounded; see Capture support and limits.
- Screenshots, console messages and notes need manual privacy review; Recorder has no pixel-redaction editor.
- Generated scripts need setup, safe test data and assertions. Recorder does not assess test outcomes.
- Backend correlation requires connected recording and an application that logs the identifiers. Header injection is not limited by capture domain rules.
- Downloads include session.md and notes.md when saved annotations exist. The downloadable sample is a real reproduction archive; its files reflect that recording.

## Who made it

We are backend developers. For years we were on the other end of the handoff, across dozens of apps and millions of lines of code: a screenshot, a sentence, and no way to find the request in the traces and logs. We built the capture side of the answer. The reproduction ID exists because it is the thing we always wanted and never got.

Fairlead is a product of Allyx, Inc. The report covers what we need as backend developers. If your team's bar is different, a QA step or a field the report should carry, tell us:

Resources:

- [Documentation](https://fairleadhq.com/docs/recorder/) — Recording, evidence review, downloads, connected workflows and privacy.
- [Capture support and limits](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) — Recording retention, supported evidence, and capture boundaries.
- [Artifact formats](https://fairleadhq.com/docs/recorder/schema/) — Runtime Report, local files and the sample reproduction archive.
- [Sample bundle ZIP](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip) — Real reproduction: Blocked tag stays after card leaves the Blocked lane.


---

# Fairlead platform: Give quality work its own capacity

Canonical: https://fairleadhq.com/platform/

Updated: 2026-09-29
Publication state: published
Product version: platform

Agent summary: Fairlead adds autonomous quality engineering capacity alongside development. Fix investigates bugs and delivers fixes with reproduction tests; Test generates and validates unit tests. Teams set scope and review changes. Product calculators use work-time baselines and explicit assumptions to estimate capacity and cost. Human review remains part of the workflow. Rebalance, Select and Replay are in development.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Autonomous quality engineering that keeps pace with code creation, so your team can keep the roadmap moving.

- Your project: Code, bug reports and available telemetry
- Fairlead: Investigate, generate changes and run checks
- Your team: Review changes and decide what to merge

## Keep the roadmap moving

As teams use AI to produce more code, investigation, testing and validation need capacity to keep pace.

- More changes to understand: Every change needs checks against the behavior your users depend on. Failures need context, reproduction and investigation.
- The same people, more quality work: Developers still own features, architecture and product decisions. Quality work draws on the same time and attention.

- 20 to 30% of developer time goes on QA
- 15 to 40% test coverage is where most teams sit
- 30 to 100× more to fix a defect in production than while coding

Add capacity for that work, so your team has more room to build what matters.

## Quality work runs alongside development

Run bug fixing and test generation against your existing repositories and tools, while your team continues planned work.

- Your team. Set the priorities: Choose the bugs, services and coverage gaps that matter to your project.
- Fairlead. Execute the workflow: Investigate failures or plan tests using the code and project context you provide.
- Your team. Keep building: Continue feature work with the development tools and coding assistants you already use.
- Fairlead. Work through the checks: Generate code or tests, run the relevant checks and repair failed attempts within the workflow's limits.
- Your team. Review and decide: Assess the changes against your requirements. Your team decides what to merge.
- Fairlead. Deliver reviewable results: Return pull requests with code and tests, or findings and evidence when work remains unresolved.

## How the platform works

Fairlead takes in your tickets, code and telemetry, and returns fixes, tests and context to your repository, your team and your IDE.

- What comes in: Tickets that QA files with enriched descriptions from Fairlead Recorder, your codebase, and logs and observability data where available. The Fairlead agent runs beside your application and passes on telemetry from manual checks and end-to-end test runs, whether they use Selenium, Cypress, Tricentis, Playwright, Browserbase or another runner.
- What the platform does: Fairlead stores the telemetry, code and tickets, and its products work from them to find the affected code, fix bugs, gather context, measure coverage and generate tests.
- What comes out: Bug fixes and tests reach your codebase through git and CI, reports reach your users and stakeholders, and context reaches your IDE or coding agent over MCP.

[How Fairlead Fix works, step by step](https://fairleadhq.com/platform/products/fix/#how-title)

[How Fairlead Test works, step by step](https://fairleadhq.com/platform/products/test/#how-title)

Repository access and a working build environment are required. Backend correlation also needs configured request headers and server logs.

## More room for the work that matters

Keep engineering judgment where it belongs, with the people who know the product.

- Features can move alongside investigations: A bug-fixing run can progress while developers continue planned work, with findings available when their input is needed.
- Review starts with a concrete change: Inspect the fix, reproduction tests and check results together. Human review stays part of the process.
- Test work has a place in the schedule: Run test generation against selected code and review the coverage added, along with scenarios that could not be completed.

| | Typically | With Fairlead |
| --- | --- | --- |
| Test coverage, within weeks | 15 to 40% | 80%+ |
| Developer time on QA | 20 to 30% of capacity | Under 5% |
| Bug fix cycle time | About 7 hours a bug | About 15 minutes |
| Coverage drift | Falling about 1% a month | Held above 80% |
| Preventable defect cost, mid-size project | $30,000 to $50,000 a month | Largely prevented |
| Engineering capacity returned to feature work | Lost to QA and bugs | About a third |

## One platform, a product for each bottleneck

Each product takes on one kind of quality work. Fairlead Fix, Fairlead Test and Fairlead Recorder are available today, and the other three are in development.

- [Fairlead Recorder](https://fairleadhq.com/): Local-first browser bug reports, as a free Chrome extension. Available.
- [Fairlead Fix](https://fairleadhq.com/platform/products/fix/): Root-cause fixes, not stack traces. Available.
- [Fairlead Test](https://fairleadhq.com/platform/products/test/): Autonomous unit tests for existing codebases. Available.
- [Fairlead Rebalance](https://fairleadhq.com/platform/products/rebalance/): Fix the inverted pyramid. In development.
- [Fairlead Select](https://fairleadhq.com/platform/products/select/): Run only the tests a change can touch. In development.
- [Fairlead Replay](https://fairleadhq.com/platform/products/replay/): Record once, replay at scale. In development.

## Ready from day zero

Fairlead is production ready out of the box. Connect your repository, and set up secure connectivity if your environment needs it, and your first tests and fixes start landing. No lengthy implementation, no infrastructure to stand up.

### A pilot shaped around your needs

Every app and team works a little differently. When your workflow, codebase or requirements need extra care, we work with you through a hands-on pilot to adapt Fairlead and assess the results together before a wider rollout.

The timeline below is for teams that need a tailored pilot. If you're ready to connect and start, you can get going without one.

- Alignment (About a week): Agree scope and success criteria; Capture code style and standards; Map test frameworks and CI/CD; Review legacy systems and constraints
- Connect (About a week): Connect repositories and trackers; Set up secure connectivity, if required; Configure for your stack; Onboard the pilot team
- Tuning (Two to three weeks): Run bug fixing and test generation cycles; Review results with the team; Tune the quality of what comes back; Iterate until the criteria are met
- Go or no-go (About a week): Evaluate the pilot results; Reach the decision point; Formalise the operating model; Define responsibilities
- Scale up (Ongoing): Extend to more teams; Start a community of practice; Establish governance; Monitor coverage and return

### What we support today

Where a connector or a language is not listed, say so. We build them in the order people ask for them.

- Languages: Java and Python today. C#, JavaScript, TypeScript, Rust and Go are on the way. The logic is built per language rather than generated by a general purpose assistant.
- Version control: GitHub, GitLab, Azure DevOps and Bitbucket, cloud or on-premise.
- Task tracking: Jira and GitHub Issues.
- Models: Model agnostic across the major providers. Your data is never used for training or fine tuning.

[How onboarding works](https://fairleadhq.com/get-started/)

## Built to run securely

Fairlead is a managed service. There is no infrastructure to provision or maintain on your side, and the compute that does the work runs on ours.

- Integration: Connect repositories and work management tools over OAuth 2.0 or an API token. No network level access is needed for cloud hosted tools.
- Secure connectivity: For on-premise or private environments, an outbound-only TLS tunnel agent, static IP allow listing, or VPN peering.
- Data security: Encrypted in transit at TLS 1.2 or better and at rest with AES-256. Source is read only and is not stored beyond the processing window.
- Access control: Single sign on over SAML or OIDC, role based access control (RBAC), and full audit logging. Each customer environment is isolated.

[Connectivity and access](https://fairleadhq.com/get-started/#connectivity)

[Platform privacy](https://fairleadhq.com/legal/privacy/)

[Service providers](https://fairleadhq.com/legal/subprocessors/)

## Join the waitlist

Leave your work email and a line about your stack, and we will write when there is a place for you.

[Join the waitlist](https://fairleadhq.com/platform/#contact)


---

# Fairlead Fix: Root-cause fixes, not stack traces.

Canonical: https://fairleadhq.com/platform/products/fix/

Updated: 2026-09-28
Publication state: published
Product version: available

Agent summary: Fairlead Fix: Context and telemetry flow into an agentic engine that finds the root cause and writes both the fix and the reproduction tests, shipped as a PR/MR. Developers shift from firefighting to building.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Context and telemetry flow into an agentic engine that finds the root cause and writes both the fix and the reproduction tests, shipped as a PR/MR. Developers shift from firefighting to building.

Status: Available

- ~68%: Less developer time on bugs
- 159%: 1-year ROI vs manual
- ~$32K: Saved on bug fixing each month (11-dev team)
- $562: Saved per bug

## How it works

1. Describe: Start with a bug report and reproduction evidence, such as a Recorder session or a triaged test failure.
2. Locate: Connect the failure to source code and available logs. Correlation requires configured request headers and backend logging; account-free Recorder sessions do not send these headers.
3. Explain: Investigate the cause and affected code. When location or cause stays unresolved, the findings and raw evidence go to your team as a report or over MCP.
4. Reproduce: Check the baseline build and available unit tests, then create a test that fails on the reported bug. Baseline failures stop the run; services without tests skip the baseline test check.
5. Fix: Change the code and run reproduction and regression checks. Failed checks return to the test or fix; unresolved failures hand over what the run found.
6. Deliver: Deliver a pull or merge request per affected service. Reproduction tests and fixes are separate commits. Your team decides whether to merge.

## What it does

- Context & telemetry ingestion: Tickets, source, logs, traces, and a user-reproduced session are captured at both client and server levels.
- Agentic root-cause analysis: The core agent platform explores the failure and pinpoints the single root cause, not just a stack trace.
- Fix + reproduction tests: Generates the code fix and the reproduction tests together, so the bug stays fixed.
- Delivered where you work: PR/MR to your VCS, plus insights to dashboards, IDE/CLI, test frameworks, and an Insights MCP.

## Outcomes

- ~6.5 hrs: Saved per bug
- 1.3×: More bugs fixed vs manual, to start with
- 0 hrs: Developer time consumed (steady state)
- ~15 min: Bug-fix cycle time
- ~$32K: Saved each month (11-dev team)
- Connect your repository, build environment and telemetry before running Fix.
- To link browser requests to backend logs, enable correlation headers and retain them in server logs.

## Autonomous bug fixing: four approaches

Same bug, radically different time and cost depending on the level of automation.

| Stage | Manual | AI-augmented | Semi-Autonomous | Fairlead Fix |
| --- | --- | --- | --- | --- |
| How it works | Developer investigates and fixes | AI suggests, dev drives fix | AI diagnoses & generates fix, dev reviews | diagnoses, fixes, validates, delivers |
| Diagnose (root cause) | ~5h 15m | ~4h 30m | ~30m | 0m (fully automated) |
| Fix (reproduction, code, tests, PR) | ~1h 15m | ~1h | ~1h | 0m (fully automated) |
| Review (approve) | ~15m (by another dev) | ~15m (by another dev) | ~15m (by another dev) | 15m (manual review) |
| Performance limit | Dev capacity | Dev capacity | Dev capacity | Machine speed |
| Total | ~6h 45m (all dev time) | ~5h 45m (dev + tool) | ~1h 45m (review + human fallback) | 15m (on review) |

## Your ROI report

Estimates include 15 minutes of review per bug. Request the full cost breakdown and assumptions for your team by email.

[Get your full report](https://fairleadhq.com/platform/products/fix/#estimate)


---

# Fairlead Test: Autonomous unit tests for existing codebases.

Canonical: https://fairleadhq.com/platform/products/test/

Updated: 2026-09-21
Publication state: published
Product version: available

Agent summary: Fairlead Test: A reliable algorithmic workflow that raises coverage with high-quality unit tests, delivered as pull requests, with zero developer effort. Model-agnostic across leading models, with per-language logic built for each codebase.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Unit tests for the codebase you already have, generated per language, compiled and run before they reach you, and delivered as pull requests.

Status: Available

- 80%+: Coverage lift in weeks
- 0 min: Developer time per test
- ~60%: 1-year ROI (cost savings vs manual)
- ~$5.3M: Expected monetary value in the first year
- ~$71K: Saved vs manual (1 yr)

## How it works

1. Measure: Build the service and measure coverage per file and per method at the start of every run, limited to the paths and classes you choose.
2. Rank: Decide what to test first. By coverage gaps alone, or map-aware, which puts untested code first and then code that git history shows is often fixed or keeps changing.
3. Screen: Skip trivial methods and look for suspected bugs. With Fairlead Fix enabled, a suspected bug gets its own PR/MR with the fix and a regression test; otherwise that code is left out.
4. Plan: Write test scenarios for each method, and confirm the existing test suite passes before any test is added.
5. Write: Generate tests per language, today Java, C# and Python. Each test must compile and pass, and the full suite must still pass. Failed checks are repaired or replanned within limits.
6. Hand over: Not every scenario can be tested as the code stands, because of its architecture or your team's conventions. Nothing is dropped. Blocked scenarios, what blocks each one, and failed test drafts go to your team as a report or over MCP, for a developer or an agent to pick up.
7. Deliver: Deliver a pull or merge request per repository, one commit per service, with a manifest of what was covered and what was left out. Your team decides whether to merge.

## What it does

- Coverage analyser and strategy planner: Slices the codebase by coverage and criticality, then plans where new tests deliver the most value.
- Language-specific generation: Logic built per language, Java and Python today, with C#, JavaScript, TypeScript, Go and Rust on the way. Tests compile, run, and reflect real usage from the first commit.
- Model-agnostic, language-specific: Model-agnostic across major providers, with logic built for each language, not a generic assistant that treats every codebase the same. Your code stays private throughout.
- Delivered as pull requests: Tests land as pull requests in your repository, which makes refactoring safe and takes risk out of modernisation work.

## Outcomes

- 0 hrs: Developer time
- 80%+: Coverage, within weeks
- 5×: Lower cost per test than by hand
- Coverage is maintained automatically as the code grows.


---

# Fairlead Rebalance: Fix the inverted pyramid.

Canonical: https://fairleadhq.com/platform/products/rebalance/

Updated: 2026-10-10
Publication state: published
Product version: in-development

Agent summary: Fairlead Rebalance: Push slow, flaky end to end and manual tests down to fast, reliable layers. Analyze coverage and criticality to keep the same coverage with far fewer expensive tests.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Push slow, flaky end to end and manual tests down to fast, reliable layers, and keep the same coverage with far fewer expensive tests.

Status: In development

- Up to 70%: Lower testing cost
- 80%: Faster feedback
- ~10×: More unit tests

## How it works

1. Map: Read every suite, from manual cases to unit tests, and count the checks in each layer.
2. Trace: Record the code each test runs, across the services it crosses, so every check has a footprint.
3. Score: Weigh each end to end and manual check by its cost, its criticality and its flakiness. A check already covered lower is removed, a critical journey stays end to end, and the rest can move.
4. Push down: Rewrite each check that can move in the lowest layer that still proves it, unit first, then integration, then API.
5. Verify: Keep a new test only when it covers the same code, passes and stays stable on reruns. A coverage gap is rewritten, or the original check stays.
6. Deliver: Deliver a pull or merge request per repository with the faster tests and the checks they replace, a report of each check kept and why, and the layer mix before and after.

## What it does

- Coverage and criticality analysis: Finds which expensive end to end checks can move to faster, cheaper layers without losing coverage.
- Push tests down the pyramid: Replaces slow, flaky end to end tests with deterministic integration and unit tests.
- Grow the base: Grows unit (~10×) and integration, the layers usually written as an afterthought.
- Shrink the top: Reduces the brittle manual and end to end tests that bloat scope every release.

## Target outcomes

- Up to 70%: Lower testing cost
- 80%: Faster feedback
- The same coverage, with far fewer end to end tests.


---

# Fairlead Select: Run only the tests a change can touch.

Canonical: https://fairleadhq.com/platform/products/select/

Updated: 2026-09-21
Publication state: published
Product version: in-development

Agent summary: Fairlead Select: Shift left: select and run only the tests affected by each code change, directly in CI/CD. Instant per-commit feedback instead of hours-long suites, so bugs are caught in minutes, not days.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Run only the tests each change can affect, directly in CI. Feedback arrives on every commit in minutes, not after hours-long suites.

Status: In development

- 153: Of 9,850 tests run for one pull request
- ~12×: Cheaper to fix a defect at the pull request than at integration
- 0: Full-suite runs per pull request

## How it works

1. Parse: Read each commit of your services method by method, so a method keeps its identity when its body changes.
2. Record: The Fairlead agent runs inside your services in CI and staging. Unit, integration, API and end to end tests, and your QA team's manual sessions, carry x-fairlead-* headers, so every method a test executes is credited to that test.
3. Map: Join the two into a footprint map, kept current as your tests run. For every method, the tests in every stage that reach it.
4. Diff: Compare each pull request with its base, method by method. Methods are modified, deleted or added.
5. Match: Find the tests whose footprints reach the changed methods, in every stage, and the manual cases that reach them. A new method no test reaches is flagged as an untested change, and goes to Fairlead Test when it is enabled.
6. Deliver: Run the impacted tests as a check on the pull request, and give QA the manual cases worth rechecking. The same footprints give coverage per stage, over the API and in the control plane.

## What it does

- Change-impact mapping: Records which methods every test executes, in every stage, so it knows exactly which tests a given change can affect.
- Relevant subset per commit: Runs only the affected tests at the right time, directly in the CI pipeline.
- Shift left: Brings expensive end to end and integration tests into CI without the hours-long wait.
- Lower cost and time: Cuts both the cost and the time to resolve defects by catching them per commit.

## Target outcomes

- Feedback on every commit, in minutes rather than hours of CI.
- Lower CI cost, and less time to resolve a defect.


---

# Fairlead Replay: Record once, replay at scale.

Canonical: https://fairleadhq.com/platform/products/replay/

Updated: 2026-10-10
Publication state: published
Product version: in-development

Agent summary: Fairlead Replay: Record manual sessions during development, replay and verify the bulk automatically so QA focuses only on the failed delta, and harden the critical paths into a durable regression suite.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Record manual sessions as you build, replay them against every new build, and keep only the critical paths as a regression suite.

Status: In development

- Up to 70%: QA team reduction
- 80%: Target verified automatically
- 0: Scripts to write

## How it works

1. Record: A person explores the new feature once, and each manual session becomes a recorded test. No scripts are written.
2. Replay: Every new build replays every recording.
3. Verify: Each replay is checked automatically. In the sample cycle 270 of 300 are verified, and only the 30 that fail go back to a person, with a pass or fail report per test.
4. Sort: When the feature ships, the critical paths are kept and the rest of the recordings are dropped, so nothing is left to maintain.
5. Harden: The kept paths become a durable end to end suite, generated from the recorded test code, and API and integration tests are derived from the same recordings.
6. Deliver: Deliver a pull or merge request per repository with the end to end suite and the API and integration tests.

## What it does

- Record without scripts: Record manual test actions during development for 100% coverage with no script writing.
- Verify automatically: Replay and verify automatically, with a target of 80% verified without a person, so QA focuses only on the failed delta.
- Drop the rest at release: The recordings that are not kept are dropped at release, so nothing is left behind to maintain.
- Harden the critical paths: The critical paths become a durable end to end regression suite.

## Target outcomes

- Up to 70%: QA team reduction
- 80%: Target verified automatically
- 0: Added headcount


---

# Pricing: Pay for results, nothing else

Canonical: https://fairleadhq.com/pricing/

Updated: 2026-09-22
Publication state: published
Product version: platform

Agent summary: Fairlead pricing: a flat rate per delivered result, $6 a unit test and $18 a bug fix on pay as you go, $5 or less and $15 or less on a monthly commitment, custom on Enterprise $4 or less a test. A run that delivers nothing is not charged. Access is by waitlist for now; when a place opens, the trial is five runs, with no card charged. Prices in USD; taxes may apply. The Fairlead Recorder is free on your own or with your team, and needs no plan.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


No charge for usage, compute, seats or time. You pay when Fairlead delivers a result, a passing test or a verified fix landing in your repository. No result, no charge.

## Five free runs when your place opens, on any plan

Join the waitlist, and when we write you start with real pull requests into your repository, up to 30 tests and 5 bug fixes a run. No card charged. The trial ends after five runs or two weeks, whichever comes first.

- 5: Free runs, on any plan
- 30: Unit tests a run
- 5: Bug fixes a run
- $0: Charged to a card

## The three plans

| | Pay as you go | Committed | Enterprise |
| --- | --- | --- | --- |
| A unit test | $6 | $5 or less | From $4 |
| A bug fix | $18 | $15 or less | Custom |
| Commitment | No commitment | Monthly results commitment | Annual or multi-year |
| Billing | Card | Card or invoice, monthly or annual | Invoice, on an order form |
| Support | Email and self-serve documentation | Priority support and guided onboarding | A dedicated success manager and technical account manager, with an SLA |
| Deployment | Managed service | Managed service, or your own VPC | Your VPC, or a private edge |
| Governance | Standard | Single sign on and usage analytics | Advanced audit, roles and SCIM, a security review and a signed DPA |
| Integrations | All version control and issue tracker integrations | All version control and issue tracker integrations | All of them, plus custom integrations |

Each plan includes everything in the plan before it. Prices in USD; taxes may apply.

## Fairlead Recorder is free, with no plan

The Recorder is the Chrome extension that records a browser check and the evidence behind it. It costs nothing on your own or with your team, and needs none of the plans above.

- On your own: Record, review and download in your browser. No account. [The Recorder on your own](https://fairleadhq.com/)
- With your team: Sign in to your team's Fairlead project. One setup decides what every tester records and redacts, and reports go to Jira, GitHub or Azure DevOps. [The Recorder for teams](https://fairleadhq.com/platform/recorder/)

## What you are charged for

- A passing unit test (per test): A complete, merge-ready unit test written into your codebase. Charged only when it ships.
- A verified bug fix (per fix): Root-caused, fixed and verified, delivered as a pull request. Charged only on delivery.
- A run that delivers nothing (no charge): Outcomes, not attempts. You are never billed for usage, compute or time spent.

## In every plan

- Fairlead Fix and Fairlead Test, at full quality
- Every supported language and framework
- Delivery as a pull request into your repository
- All version control and issue tracker integrations
- A model-agnostic engine
- Your code never trains any model

## Questions

### When can I start the free trial?

Join the waitlist and we will write when there is a place for you. The trial then ends after five runs or two weeks, whichever comes first. The two week limit exists to trigger data wiping under our retention policy, because we do not want to hold your code longer than we need to. Nothing is automatic and the trial never charges a card. When you are ready you pick a plan; if you do not, access pauses and your data is cleared.

### What exactly am I paying for?

Results, and nothing else. A passing unit test costs a flat rate per test, a verified bug fix a flat rate per fix. We never bill for usage, compute, seats or time. If a run delivers nothing, you pay nothing.

### Can I change plan later?

Yes. Move from pay as you go to a commitment when predictable volume makes the lower rate worth it, and to Enterprise when you need a private edge deployment and advanced governance. Committed can already run in your own VPC. No migration, and the same engine throughout.

### Do you charge per seat, or for usage?

Neither. You pay for delivered work, tests written and bugs fixed, never for the number of developers or the compute we use. Invite the whole team.

### Is my code safe?

Your code never trains any model, the engine is model-agnostic, Committed can run in your own VPC, and Enterprise in your VPC or behind a private edge. Source is read only and is not stored beyond the processing window. Get started sets out the full connectivity model. [How we connect](https://fairleadhq.com/get-started/#connectivity)


---

# Get started: Ready from day zero

Canonical: https://fairleadhq.com/get-started/

Updated: 2026-09-22
Publication state: published
Product version: platform

Agent summary: Getting started with Fairlead: connect a repository and optionally secure connectivity, and results begin. Enterprise engagements run a five phase pilot over roughly six to eight weeks to a go or no-go decision. The connector is outbound only, identity aware, isolated per customer and fully logged.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Fairlead is production ready out of the box. Connect your repository, and set up secure connectivity if your environment needs it, and your first tests and fixes start landing. No lengthy implementation, no infrastructure to stand up.

## How you start

On a standard stack it takes four steps. Complex, regulated or legacy environments add a structured pilot.

1. Join the waitlist: Leave your work email and a line about your stack. We write when there is a place for you.
2. Connect your repository: Connect repositories and your tracker over OAuth 2.0 or an API token. Cloud hosted tools need no network level access.
3. Set up secure connectivity, if you need it: For on-premise or private environments, a connector inside your network dials out. Nothing inbound is opened on your side.
4. Your first tests and fixes land: They arrive as pull requests into your repository.

## A pilot shaped around your needs

Every app and team works a little differently. When your workflow, codebase or requirements need extra care, we work with you through a hands-on pilot to adapt Fairlead and assess the results together before a wider rollout.

The timeline below is for teams that need a tailored pilot. If you're ready to connect and start, you can get going without one.

### Alignment (About a week)

- Agree scope and success criteria
- Capture code style and standards
- Map test frameworks and CI/CD
- Review legacy systems and constraints

### Connect (About a week)

- Connect repositories and trackers
- Set up secure connectivity, if required
- Configure for your stack
- Onboard the pilot team

### Tuning (Two to three weeks)

- Run bug fixing and test generation cycles
- Review results with the team
- Tune the quality of what comes back
- Iterate until the criteria are met

### Go or no-go (About a week)

- Evaluate the pilot results
- Reach the decision point
- Formalise the operating model
- Define responsibilities

### Scale up (Ongoing)

- Extend to more teams
- Start a community of practice
- Establish governance
- Monitor coverage and return

## How we connect, without opening a port

A connector inside your environment dials out. Nothing dials in. Every request from Fairlead is checked against identity and policy at the edge before it reaches a service of yours.

### Your environment

- No open ports: The connector dials out to the edge. Nothing inbound is opened on your side, so no public IPs and no firewall changes.
- Private connectivity: Reach internal services over TCP, UDP and ICMP. Map specific hostnames or IP ranges, so only what you expose is reachable.

### Zero Trust edge

- Identity aware: Every request is authenticated and authorised against identity, device posture and network context before it reaches a service.
- Isolated per customer: A separate account for each customer keeps tenants apart, with governance and policy scoped to one environment.
- Fully logged: Access policies, identity checks and gateway events are logged end to end, for a reviewable audit trail.

## Built to run securely

Fairlead is a managed service. There is no infrastructure to provision or maintain on your side, and the compute that does the work runs on ours.

- Integration (OAuth 2.0, API token): Connect repositories and work management tools over OAuth 2.0 or an API token. No network level access is needed for cloud hosted tools.
- Secure connectivity (TLS tunnel, IP allow list, VPN peering): For on-premise or private environments, an outbound-only TLS tunnel agent, static IP allow listing, or VPN peering.
- Data security (TLS 1.2+, AES-256): Encrypted in transit at TLS 1.2 or better and at rest with AES-256. Source is read only and is not stored beyond the processing window.
- Access control (SAML, OIDC, RBAC, Audit log): Single sign on over SAML or OIDC, role based access control (RBAC), and full audit logging. Each customer environment is isolated.

## What we support today

Where a connector or a language is not listed, say so. We build them in the order people ask for them.

- Languages: Java and Python today. C#, JavaScript, TypeScript, Rust and Go are on the way. The logic is built per language rather than generated by a general purpose assistant.
- Version control: GitHub, GitLab, Azure DevOps and Bitbucket, cloud or on-premise.
- Task tracking: Jira and GitHub Issues.
- Models: Model agnostic across the major providers. Your data is never used for training or fine tuning.


---

# Fairlead Recorder for teams: The same report from every tester, filed to your issue tracker.

Canonical: https://fairleadhq.com/platform/recorder/

Updated: 2026-09-26
Publication state: published
Product version: connected-preview

Agent summary: Fairlead Recorder for teams is the Recorder extension signed in to a Fairlead project. The project sets the recording scope, redaction keys and storage policy for every tester. Reports are stored in the project's Data Plane, can be given a generated description, and are filed to Jira, GitHub or Azure DevOps through Bridge. Selected content is sanitized; screenshots, console messages and notes need review.

## Prerequisites

- Chromium-compatible browser
- A Fairlead account in a project an admin has set up

## Inputs

- A manual browser test session, recorded under the project's settings

## Outputs

- An issue in the project's tracker, with the tester's text and the screenshots they select
- The redacted report, stored in the project's Data Plane unless the project turns storage off

## Limitations

- Test management systems are not connected. Filing a test result to one is in research.
- Filing works with Jira, GitHub and Azure DevOps.
- A generated description needs the project's Data Plane. A project that turns storage off gets none.
- On the Fairlead cloud Data Plane, reports are stored on Fairlead-operated servers.
- Connected correlation headers can reach third-party request destinations; capture domain rules do not limit injection.

## Permissions

- Active-tab access for the page being recorded
- Browser debugging access while recording network and console activity

## Privacy

- Sensitive-value rules apply during capture and report assembly; they do not cover all content.
- Bridge handles issue commands and screenshot transfers to the tracker.


An admin sets recording and redaction once, in the project. Every tester follows it and files from the side panel, evidence attached.

Review captured content before sending it.

## Free. Forever.

The extension and its team features cost nothing. No plan, no trial, no seat fee.

[The Recorder on its own, without an account](https://fairleadhq.com/)

## One project setup reaches every tester.

An admin sets the recording scope, the redaction keys and the storage policy once, in the project. Each tester's extension receives them when it signs in, so the whole team captures and redacts the same way.

A signed-in tester cannot edit these settings from the extension. Changing them is a project change, made in one place.

What a tester's extension receives from the project. Sample values.

```text
project     checkout-web
record      shop.example, *.shop.example
network     api.shop.example
redact      authorization, set-cookie, session_token,
            customer.email, card_number
storage     Save recorded data in Data Plane: on
            Data Plane: Fairlead cloud
file to     Jira  SHOP
            GitHub  your-org/checkout-web
```

## Where each part goes

The project's settings come down to the extension when it signs in. Automatic redaction covers selected keys and structures; inspect the remaining content. While recording, the extension adds request IDs to the page's requests, third-party ones included, so your backend can log them. The issue text and chosen screenshots go through Bridge to your tracker. The report goes to your project's Data Plane, the service that stores reports and can write a description from one.

## Find a recorded request in your backend logs.

While recording, the extension sends `x-fairlead-reproduction-id` with intercepted requests. Optional issue and per-request identifiers help narrow the search when your application logs them.

Header injection is not restricted by the project's capture rules, so the identifiers also reach third-party requests. Recording on your own sends none.

[Configure and check correlation](https://fairleadhq.com/docs/recorder/session-correlation/)

## The issue comes with a way into your logs.

Every request the tester recorded carried `x-fairlead-reproduction-id` down to your backends. Log it, and a developer finds where that QA session entered your system, in traces and logs, instead of guessing from a screenshot.

- Reproduction ID: One per session, on every recorded request. Search traces and logs for it to find the session's entry points. It is kept in the stored report.
- Title and description: Written by the tester, or generated from the stored report and then edited before filing.
- The Fairlead block: The tester's reproduction notes, in a fenced block of their own. If an existing description conflicts, review it in the tracker before choosing append or replacement.
- Screenshots: The included images. Pixels are not automatically masked; inspect each image before submission.

Your services need to log the headers; that is a one-time setup. When the tester picks the issue before recording, requests also carry its key, so the issue number finds them too.

## What it files to today.

An admin connects the destination once, in Control Plane. Testers never enter tracker tokens.

- Jira: A new issue or an existing one, with the tester's text and the screenshots they select. [Filing an issue](https://fairleadhq.com/docs/recorder/issue-trackers/)
- GitHub: A new issue or an existing one, with the tester's text and the screenshots they select. [Filing an issue](https://fairleadhq.com/docs/recorder/issue-trackers/)
- Azure DevOps: A new issue or an existing one, with the tester's text and the screenshots they select. [Filing an issue](https://fairleadhq.com/docs/recorder/issue-trackers/)
- Test management: No direct connection yet. Attach the downloaded evidence to the case or run by hand. [Attaching evidence to a TMS](https://fairleadhq.com/docs/recorder/tms-evidence/)

## You choose where reports are kept.

The Data Plane is the service that stores your project's reports and writes descriptions from them. Each project names one, and where it runs is your choice.

- Run by Fairlead: The Fairlead cloud Data Plane. Reports are stored on Fairlead-operated servers.
- Run by you: A Data Plane your organization runs and enrols, inside your own infrastructure. Fairlead's servers never hold the report.
- Or not kept at all: A project can turn storage off. Nothing is sent to a Data Plane, and there is no generated description. Filing to the tracker still works.

## On your own or with your team

It is the same extension. The difference is whether it signs in to a project.

| | On your own | With your team |
| --- | --- | --- |
| Account | None | A Fairlead account in your team's project |
| Settings | Built in. Recording stays on the site you start on | Set by the project for every tester |
| Redaction | Built-in rules, plus manual review | Project rules, plus manual review |
| The report goes to | A file you download | Your project's Data Plane, unless storage is off |
| Filing an issue | You attach the file yourself | From the side panel, to Jira, GitHub or Azure DevOps |
| Written description | Not available | Generated from the stored report |
| Session ID in your logs | No headers sent | Identifiers sent during recording; backend logging required |

## Who made it

We are backend developers. For years we were on the other end of the handoff, across dozens of apps and millions of lines of code: a screenshot, a sentence, and no way to find the request in the traces and logs. We built the capture side of the answer. The reproduction ID exists because it is the thing we always wanted and never got.

Fairlead is a product of Allyx, Inc. The report covers what we need as backend developers. If your team's bar is different, a QA step or a field the report should carry, tell us:


---

# Fairlead platform overview
Canonical: https://fairleadhq.com/docs/
Markdown: https://fairleadhq.com/docs/index.md

How the products work together to improve software quality and keep it from slipping as code changes.

Updated: 2026-10-07
Publication state: published
Product version: platform

Agent summary: Fairlead connects browser evidence, bug investigation, and unit test generation with team review. Recorder captures evidence, Fix proposes fixes with reproduction tests, and Test adds unit tests. Rebalance, Select, and Replay are in development to help maintain quality as code changes.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Fairlead is a quality engineering platform for finding defects, fixing their causes, and building tests that catch regressions. Its products work from your project's code, test results, and recorded evidence. Your team sets the priorities and decides which changes to merge.

## How the platform works

Start with a reported problem or a gap in test coverage. Fairlead uses the project context to investigate the problem or generate tests, runs checks, and returns changes and findings for review.

Browser checks and test runners provide application telemetry. Recorder enriches tickets with browser evidence. Tickets, code, and available logs and observability feed the Fairlead platform. Its products return fixes and tests to the repository, reports to the team, and context to an IDE or coding agent over MCP.

A browser recording can supply the evidence for a bug investigation. Test generation can start directly from the codebase. Both paths contribute changes that your team can review and keep in the repository.

## Products

| Product | Role in the platform |
| --- | --- |
| [Recorder](https://fairleadhq.com/docs/recorder/) | Capture browser actions, requests, console output, and screenshots taken during a check. Review and share the evidence to explain what happened. |
| [Fix](https://fairleadhq.com/platform/products/fix/) | Investigate a reported defect using code and available evidence. Propose a fix with reproduction tests, run checks, and deliver a pull or merge request for review. |
| [Test](https://fairleadhq.com/platform/products/test/) | Find coverage gaps in selected code, generate unit tests, compile and run them, and deliver the tests as pull requests. |
| [Rebalance](https://fairleadhq.com/platform/products/rebalance/) (in development) | Identify checks that can move from expensive manual or end-to-end tests to faster integration and unit tests while preserving coverage. |
| [Select](https://fairleadhq.com/platform/products/select/) (in development) | Use the relationship between code and tests to select which tests to run for each change. |
| [Replay](https://fairleadhq.com/platform/products/replay/) (in development) | Turn recorded manual checks into repeatable checks against new builds, and develop critical paths into regression tests. |

## Improve quality, then maintain it

Recorder helps make a problem understandable. Fix addresses its cause and adds a test for the failing behavior. Test broadens coverage beyond individual reported bugs. Together, these activities turn findings into fixes and lasting tests.

As the codebase grows, the planned roles of Rebalance, Select, and Replay are to keep that testing useful and manageable: move checks to the right layer, run the relevant tests for a change, and repeat important user journeys. New failures feed the next investigation, and the resulting tests protect the behavior on later changes.

The shared context is your project: its code, issues, evidence, and tests. You choose the scope of work; Fairlead returns proposed changes, check results, and findings for your team to assess. Repository access and a working build environment are needed for Fix and Test.

## Recorder documentation

- [QA guides](https://fairleadhq.com/docs/recorder/): record browser checks, assess outcomes, and share evidence.
- [Developer guides](https://fairleadhq.com/docs/recorder/developers/): investigate failures, connect evidence to backend logs, and generate starter test scripts.
- [Platform setup](https://fairleadhq.com/get-started/): connect your project and prepare the environment for platform work.

## Shared concepts

[Recording identifiers](https://fairleadhq.com/docs/recorder/developers/session-identifier/) help connect browser evidence with backend logs. This requires connected recording and server-side logging of the supplied headers. Recorder can also be used [locally, without an account](https://fairleadhq.com/docs/recorder/local-and-connected/).

## For agents

Use **Open Markdown** on a documentation page to read or copy its Markdown version. [`/llms.txt`](https://fairleadhq.com/llms.txt) indexes the published content, and [`/llms-full.txt`](https://fairleadhq.com/llms-full.txt) collects it in one file.

---

# Recorder QA guides
Canonical: https://fairleadhq.com/docs/recorder/
Markdown: https://fairleadhq.com/docs/recorder.md

Execute browser tests, review outcomes, and share evidence with your team.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: QA guides for Recorder test execution, capture, review, results, and evidence handoff, with separate developer documentation.

## Prerequisites

- A browser application to test

## Inputs

- A test to execute
- A bug to reproduce
- Recorded evidence to investigate

## Outputs

- A documentation path for test execution
- Result evidence
- Defect diagnosis
- Test export

## Limitations

- The retained timeline is bounded

## Permissions

- None declared.

## Privacy

- Inspect logs and images before sharing

Use Fairlead Recorder to capture browser test execution and preserve evidence of what happened. A session can support a bug report, a record that no issue was observed within the tested scope, or evidence attached to a test run in your test-management system (TMS). These guides cover preparation, recording, review, results, and reuse.

## Choose a path

- **QA engineers:** [Choose a testing workflow](#testing-workflows), [record a test session](#record-a-test-session), then [report results and share evidence](#report-results-and-share-evidence).
- **Developers:** Open the [developer documentation](https://fairleadhq.com/docs/recorder/developers/) for diagnosis, backend correlation, test generation, and format reference.
- **Teams using Fairlead projects:** [Connect your project](#connect-your-project) for configured issue destinations and stored sessions.

Capture begins after Start and follows the [retained-timeline and session limits](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention). Downloads save evidence files in a folder. Inspect console output and screenshot pixels before sharing; automatic redaction does not cover everything.

## Get started

- [Install and open Recorder](https://fairleadhq.com/docs/recorder/installation/). Add Recorder to Chrome, pin it to the toolbar, and open the side panel.
- [Recorder overview](https://fairleadhq.com/docs/recorder/overview/). Tour the side panel, recording controls, and viewer sections, with their purpose, available actions, and key limits.
- [Keyboard shortcuts](https://fairleadhq.com/docs/recorder/shortcuts/). Control recording setup, move through Viewer evidence, and edit a session from the keyboard.
- [Record your first test](https://fairleadhq.com/docs/recorder/quick-start/). Define the check and expected result, Start, execute, Stop promptly, review evidence, and record the observed outcome.
- [Local recording and connected projects](https://fairleadhq.com/docs/recorder/local-and-connected/). Account-free capabilities, signing in, project prerequisites, available destinations, and session provenance.
- [What Recorder captures](https://fairleadhq.com/docs/recorder/captured-data/). Actions, requests, console, screenshots, environment, lifecycle and performance evidence, with capture limits.

## Testing workflows

These are recommended blueprints you can adapt to your team's process. Each explains the Recorder controls, evidence checks, and handoff for the task. Start with [Choose a workflow](https://fairleadhq.com/docs/recorder/testing-workflows/) for shared setup, capture, and download details, or open the job you need to complete:

- [Execute a test case](https://fairleadhq.com/docs/recorder/test-execution/). Capture expected-result checks, annotate the deciding evidence, and save the attempt for its case/run.
- [Reproduce a reported bug](https://fairleadhq.com/docs/recorder/bug-reproduction/). Capture a numbered attempt and add its result to the existing issue.
- [Report a bug from recorded evidence](https://fairleadhq.com/docs/recorder/bug-reporting/). Find the failing action, annotate requests and screenshots, and assemble the issue without repeating a useful recording.
- [Verify a fix](https://fairleadhq.com/docs/recorder/fix-verification/). Compare the original failing evidence with a fresh attempt on the candidate build.

For particular checks or recording patterns:

- [Capture an exploratory discovery](https://fairleadhq.com/docs/recorder/exploratory-testing/). Stop at a useful observation, search its evidence, and save it before the next variation.
- [Record a smoke or regression batch](https://fairleadhq.com/docs/recorder/regression-testing/). Name, review, and download each case or checkpoint before continuing.
- [Capture accessibility test evidence](https://fairleadhq.com/docs/recorder/accessibility-evidence/). Keep keyboard events visible and annotate focus or assistive-technology observations.
- [Investigate slow or unresponsive behavior](https://fairleadhq.com/docs/recorder/slow-or-unresponsive/). Preserve the initiating action and inspect request timings, errors, and the waiting state.

## Record a test session

- [Start, stop, and reset](https://fairleadhq.com/docs/recorder/recording-lifecycle/). Side panel and in-page controls, pending starts, the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention), and resetting local evidence.
- [Navigation, tabs, and frames](https://fairleadhq.com/docs/recorder/navigation-and-frames/). SPA navigation, newly opened tabs, domain boundaries, iframe provenance, and Shadow DOM limits.
- [Screenshots and attachments](https://fairleadhq.com/docs/recorder/screenshots/). Visible viewport and area capture, clipboard and file images, inclusion controls, and unmasked pixels.

## Inspect a session

- [Open the session viewer](https://fairleadhq.com/docs/recorder/session-viewer/). Open a stopped local session, move between evidence views, return to the application, and understand snapshot/reset behavior.
- [Recorded actions and user steps](https://fairleadhq.com/docs/recorder/steps-and-events/). Individual recorded actions, event detail, selectors and labels, related evidence, and generated user steps.
- [Network requests and responses](https://fairleadhq.com/docs/recorder/network/). Search and filter requests; inspect headers, query parameters, bodies, timing, initiators, cookies, and missing or truncated content.
- [Console and browser errors](https://fairleadhq.com/docs/recorder/console/). Filter levels and sources, inspect exceptions and stack traces, and align errors with the retained timeline.
- [Add notes to evidence](https://fairleadhq.com/docs/recorder/notes/). Annotate actions, requests, fields and console entries; mark important notes; edit, delete, and follow source evidence.
- [Environment and performance evidence](https://fairleadhq.com/docs/recorder/environment-and-performance/). Browser/page context, lifecycle events, long tasks and timing evidence, and limits of recorded diagnostics.

## Report results and share evidence

- [Record test outcomes](https://fairleadhq.com/docs/recorder/test-outcomes/). Record pass, fail, blocked, or inconclusive results against stated checks; document no issue observed within a specific scope; include gaps and unexecuted steps.
- [Attach execution evidence to a TMS](https://fairleadhq.com/docs/recorder/tms-evidence/). Associate reviewed artifacts with the correct case, run, build, environment, tester, and execution time; record the result in the TMS and verify attachments are accessible.

Recorder supplies evidence for a tester to assess. A clean console or the absence of a captured error does not establish that a test passed. TMS guidance covers manual attachment or approved links where supported by your tools; it does not assume automatic result synchronization.

## Connect your project

- [Sign in and select a project](https://fairleadhq.com/docs/recorder/projects/). Control Plane authentication, assigned project profiles, session expiry, and where administrators manage configuration.
- [Understand capture rules](https://fairleadhq.com/docs/recorder/capture-configuration/). Domains, network scope, payload limits, excluded selectors, trusted iframe values, and project-sensitive-key lists.
- [Create or update an issue](https://fairleadhq.com/docs/recorder/issue-trackers/). Choose a configured tracker, find/create/update an issue, connect credentials in Control Plane, and resolve description conflicts.
- [Upload a session and enhance the report](https://fairleadhq.com/docs/recorder/session-upload/). Data Plane destinations, explicit enhancement, storage-disabled projects, and independent issue/attachment/upload outcomes.
- [Open a stored session](https://fairleadhq.com/docs/recorder/stored-sessions/). Open from Control Plane, authorization expiry, and current read-only, attachment, and test-generation limitations.

## Privacy and permissions

- [Review data before sharing](https://fairleadhq.com/docs/recorder/review-redaction/). Inspect privacy evidence, console, images, notes and payloads; use supported manual redaction and distinguish display choices from export decisions.
- [How redaction works](https://fairleadhq.com/docs/recorder/redaction-rules/). Capture-time and assembly-time sanitization; partial header masking; cookie values; project rules replacing defaults; XML/free-text gaps.
- [Browser permissions](https://fairleadhq.com/docs/recorder/permissions/). Understand browser debugging access, site scope, file access, and restricted pages.
- [Storage and data destinations](https://fairleadhq.com/docs/recorder/privacy/). Local session storage and attachments, downloads, reset, Bridge commands, Data Plane reports, and what disabling storage does.

## Troubleshooting

- [Recording and missing evidence](https://fairleadhq.com/docs/recorder/troubleshooting/). Restricted pages, start failures, debugger attachment, off-domain traffic, iframe values, unavailable bodies, and evidence outside the retained window.
- [Downloads and generated tests](https://fairleadhq.com/docs/recorder/troubleshooting-exports/). Failed or partial downloads, missing optional files, redacted values, unsupported actions, selectors, and test preconditions.
- [Sign-in, uploads, and issue submission](https://fairleadhq.com/docs/recorder/troubleshooting-connections/). No assigned profile, expired auth, missing credentials/destination, protocol mismatch, unknown timeout outcome, and partial success.

## Downloads

- [Download session artifacts](https://fairleadhq.com/docs/recorder/bundle-contents/). Local artifact files, screenshot attachments, session and notes Markdown, and partial-download recovery.

See [Developers](https://fairleadhq.com/docs/recorder/developers/) for technical reference and generated test scripts. The [Markdown version](https://fairleadhq.com/docs/recorder.md) is available for this guide.

---

# Capture accessibility test evidence
Canonical: https://fairleadhq.com/docs/recorder/accessibility-evidence/
Markdown: https://fairleadhq.com/docs/recorder/accessibility-evidence.md

A recommended blueprint for capturing keyboard and visual evidence and documenting manual accessibility observations.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Choose Test case or Explore, capture keyboard and control evidence, separate manual observations, and preserve a scoped accessibility result.

## Prerequisites

- Recorder installed; a defined manual accessibility check

## Inputs

- Expected behavior and relevant assistive-technology context

## Outputs

- A scoped finding with supporting evidence

## Limitations

- No accessibility scanner or focus-path overlay; recorded keyboard events are not a complete focus history

## Permissions

- Authorization to test the application

## Privacy

- Review evidence before sharing

This is a **recommended blueprint for collecting evidence from a manual accessibility check with Recorder**. Adapt the example to the keyboard, focus, label, or assistive-technology behavior you are checking. Recorder helps preserve the interaction and your observations; your testing process and companion tools determine the accessibility result.

The example below follows a dialog check: open it, navigate its controls with the keyboard, close it, and observe where focus returns. Use [test execution](https://fairleadhq.com/docs/recorder/test-execution/) when this is part of a larger case.

## Choose the mode and follow this 9-step path

Select **Test case** for a defined accessibility check with an authoritative case ID and a Passed/Failed/Blocked result. Select **Explore** for a newly observed keyboard, focus, label, or announcement problem; Explore has no Recorder result selector.

1. Choose the session type and enter the test case or optional issue reference.
2. In **Description**, record the build, browser/OS, assistive technology, settings, starting control, input method, and expected behavior.
3. Select **Start recording** and perform the check using the intended input method.
4. Observe focus or announcement before opening Recorder controls, then capture any visible state.
5. Select **Stop → Investigate** while the check remains in the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
6. Compare the captured input, intended control, control/page response, and your manual observation.
7. Add source comments that say which part Recorder captured and which part you observed or obtained from a companion tool.
8. For Test case, choose Passed, Failed, or Blocked; for Explore, write the scoped finding and next check in Description.
9. Review, download or send, verify the attachment/result, and only then select **New recording**.

| Evidence | Recorder supplies | You must supply |
| --- | --- | --- |
| Input sequence | Supported actions and key events; Event Log detail | Starting focus, intended input method, and missing events |
| Control identity/state | Recorded role, labels, target context, and available state changes | Expected accessibility behavior and companion-tool interpretation |
| Focus/announcement | Partial visual or page-change context | Actual focus destination or spoken announcement and how it was observed |
| Result | Test case choices only | Scoped conclusion; Explore has no result control |
| Handoff | Description, Notes, images, report/download destinations | Tool versions, capture gaps, and external TMS or issue update |

## Prepare the context the recording cannot infer

Open the application and Recorder's side panel. Select the local or connected path. Prepare safe data and put the following in your test notes for the later description:

- Application build and the task being checked.
- Browser and OS, assistive technology and version, and relevant settings.
- Zoom or other display/input conditions you changed.
- Expected behavior, such as “Escape closes the dialog and focus returns to its opening button.”

Recorder's **Environment** tab provides available browser, viewport, and page context. Add assistive-technology settings and application build yourself. Use a title such as `TC-A11Y-8 - A1 - Dialog focus return`. A found issue can prefill an unchanged Title and offer its description; add that text only when it belongs in this attempt's unified Description.

## Capture the keyboard path

1. Select **Start recording** in the side panel and wait for the active state. Put focus at the agreed starting control in the application.
2. Perform the check using the intended input method. Keep track of the relevant keys and the observed focus destination; Recorder captures selected keys and shortcuts but not a complete focus history.
3. At a visible problem, use **Capture** for the viewport or **Area** for the affected region. Include enough of the page to identify the focused control or missing/incorrect label.
4. Select **Stop**, then **Investigate**. Keep the task inside the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).

Moving to Recorder's controls can itself change keyboard focus. Observe and write down the focus result before using those controls. If the screenshot no longer shows the original focus state, say so in its note rather than presenting the later state as proof. If a screen-reader announcement matters, record the wording you actually heard in your notes; Recorder does not capture its audio.

## Connect the input, control state, and observed effect

Investigate the chain **input → intended control → page/control response → observed focus or announcement**. Recorder can support parts of this chain; preserve your manual or companion-tool observation for the parts it does not capture.

1. Open **Actions → Recorded Actions** and turn **Key actions only** off; it hides keydown events. Use **Event Log** to inspect the captured key/action sequence and times. Identify the action before the failure rather than reconstructing a complete focus order from partial events.
2. Select the relevant action. In **Target**, inspect available **Role**, **Label**, **Aria label**, visible text, selector and frame context. Confirm that these identify the control you used, especially when several controls have the same label. Recorder's readable name can include inferred context; it is not a substitute for the actual accessibility tree or spoken announcement.
3. Inspect **What changed** and **Element & form state**, when present. For an expandable control, a captured expanded-state change helps distinguish “activation did not occur” from “activation occurred but the resulting focus/announcement was wrong.” Disabled or busy state can explain another blocked interaction. Absent state is not a recorded false value.
4. Open **Page changes** or **URL changed** if the action closes a dialog or navigates. If the control fetches content, open its related request and compare **Payload/Response** with the expected content. Check **Timeline** and **Timing** before treating a loading delay as a focus failure.
5. Right-click the useful target/state field → **Pin**, or pin the whole action for a sequence-level observation. Open the screenshot and pin it separately. In **Notes**, use **View evidence** to check that both concern the same point in the task, then add the manual focus/announcement observation with **Add comment → Save comment**.

For the dialog example, evidence that Escape was captured and the dialog closed supports the first part of the expectation. Whether focus returned to the opener still needs your observed focus destination or companion evidence. A screenshot taken after opening Recorder may identify the controls but no longer show that focus state.

If the intended action was captured but its state never changed, investigate activation/control state. If state changed and new content appeared but focus or announcement was wrong, preserve those successful transitions too: they narrow what the developer needs to reproduce. If input/state is missing, report the manual observation and gap instead of inventing the missing event.

## Attach a precise observation

For an input/focus finding, select the relevant action and choose **Add note**. For a visual finding, open **Screenshots & Attachments**, select the image, and choose **Add note** there.

Write enough context to separate captured evidence from what you observed manually:

```text
Input: pressed Escape after tabbing through the dialog controls.
Expected: dialog closes and focus returns to the opening button.
Observed manually: dialog closed; focus did not return to that button.
Screenshot: captured afterwards; opening Recorder changed focus, so this image only identifies the controls.
```

Adapt the last line to the actual image. If it clearly shows the original state, say what is visible. For an announcement, name the assistive technology and quote the observed wording, rather than suggesting the recording contains audio.

Select **Important** for the deciding finding, then **Save comment**. Open **Notes**, select the item, and use **View evidence** to confirm that it points to the intended action/image. Use **Edit comment → Save comment** for corrections; a comment draft is not saved just by closing its editor.

## Add companion-tool evidence and the result

If a companion tool provides an image, open the local Viewer and use **Screenshots & Attachments → Upload image**, **Paste image**, or drop the image on that tab. When clipboard access fails, use Upload image. State the tool, version, and origin in Description.

An image added after Stop is outside the frozen recording interval. Inspect its **Outside recorded period** label and use **Include in report** if it should accompany connected submission. This does not make the pictured event part of the captured interaction. Local downloads include available attachments regardless of that report-inclusion choice.

In **Description → Split**, write:

```markdown
Check / attempt: TC-A11Y-8 / A1 — dialog focus return
Build / browser / OS: [fill in]
Assistive technology / version / settings: [fill in]
Input sequence: [keys and starting control]
Expected: [focus, label, or announcement behavior]
Observed: [specific result and how you observed it]
Evidence: [NOTES]
Companion evidence: [tool output or attachment reference]
Capture limits: [missing events or altered screenshot state]
```

Select `[NOTES]` and choose **Add → Notes**. Review **Preview**, including any bare pins inserted with the comments. The copied text will not update if you later edit a source note. Resolve any description save error before export.

## Preserve and report

Open **Privacy preview** and inspect the authored text and image pixels as well as captured fields. Select **Download report**, confirm completion in Chrome, and open the summary, `notes.md` when present, and the images. Keep companion-tool outputs with the same case/attempt.

Attach the reviewed evidence to the test result or [bug report](https://fairleadhq.com/docs/recorder/bug-reporting/), then verify the attachments before **New recording** clears the local session. If the note points to the wrong source or says **Evidence unavailable**, preserve the written observation and explain the gap; add the correct evidence if still available.

Recorder provides no accessibility scanner, focus-path overlay, or conformance verdict. Keep the conclusion tied to the particular check and the tools used. The [shared workflow guide](https://fairleadhq.com/docs/recorder/testing-workflows/) covers download recovery and handoff choices.

---

# Report a bug from recorded evidence
Canonical: https://fairleadhq.com/docs/recorder/bug-reporting/
Markdown: https://fairleadhq.com/docs/recorder/bug-reporting.md

A worked QA investigation from visible symptom through actions, sent and returned data, notes, and a developer-ready report.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use Explore to capture a new or existing issue, investigate the deciding evidence, assemble Description, and verify the tracker handoff.

## Prerequisites

- A recorded failure, or a short path to capture it

## Inputs

- Expected and actual behavior with case and run context

## Outputs

- A useful new issue or update to an existing issue

## Limitations

- Issue, attachment, and report-storage outcomes are independent

## Permissions

- Tracker access; connected project access only for submission through Recorder

## Privacy

- Review content and destination before sharing

This is a **recommended blueprint for turning a Recorder session into a bug report**. Adapt the report template and investigation depth to the defect. The useful result is a short account of how to reach the problem, what should happen, and evidence that puts the developer on the exact screen, request, or field.

If a failed-test recording already shows the problem, start with its **Investigate** viewer. You do not need another reproduction just to file a report. The steps below cover both a local file handoff and a configured tracker submission.

For a first investigation, follow the worked example below. Once the approach is familiar, use the [decision table](#4-try-to-disprove-the-explanation-before-writing-it) to choose the next evidence and the [final report example](#example-the-investigation-condensed-into-a-report) to check your handoff.

## Follow this 10-step path

1. Select **Explore**. Leave **Issue** empty for a new report, or select the issue you intend to update.
2. Write a specific Title and the shortest known path, expected result, actual result, and conditions in **Description**.
3. Select **Start recording**, capture the failure and enough surrounding state to identify it, then **Stop → Investigate**.
4. Confirm the affected subject and visible discrepancy in Screenshots & Attachments.
5. Follow the same subject through the trigger action, sent value, returned state, and later read or update.
6. Pin useful sources, then add comments explaining what they establish and what remains open.
7. Edit Description into minimal reproduction steps, expected/actual behavior, evidence, scope, and next check.
8. Review **Privacy preview**, choose the intended send action or **Download report**, and inspect the actual output.
9. Open the issue and verify its text and attachments; issue mutation, attachments, and report storage can have different outcomes.
10. Retry only the failed part, preserve the ready recording, and select **New recording** only after the handoff is usable.

## Understand the report fields and destinations

| Part | Recorder does | You decide |
| --- | --- | --- |
| **Explore** | Uses an optional issue lookup and no result selector | Whether this is a new report or an update |
| Issue lookup | Can fill an unchanged Title and offer the fetched issue description | Whether to choose **Add**; the text is appended, not synchronized |
| Description | Saves one Markdown account after a pause or blur | The minimal path, expected/actual result, evidence, and scope |
| Create | Uses Title and Description for a new issue | Whether the discovery is ready to file |
| Update | Adds Description and screenshots to the selected issue | Whether the existing description should remain unchanged |
| Replace description | Makes Description the issue description after confirmation | Whether replacement is truly intended |
| Send data to Fairlead | Stores the report without a tracker mutation | Whether report storage is the intended destination |

Older stored reports can contain a separate legacy reproduction-notes value. The current local Viewer uses Description for new edits and sends.

## Capture the failure if you do not have it yet

1. Open the application and Recorder's side panel. Use the account-free path for a local handoff or select the connected project and tracker. Choose **Explore**. Leave Issue empty for a new report or select the known issue.
2. Prepare safe data and the shortest known route to the symptom. If creating a record or changing a setting is necessary evidence, do that after Start; otherwise put it in the report's preconditions.
3. Select **Start recording**, wait for the active state, and perform the actions. When the wrong result appears, use **Capture** for the visible viewport or **Area** for a region. Include identifying context, such as both the affected card and its lane heading.
4. Capture any immediately relevant response or follow-up check, then select **Stop** and **Investigate**. Avoid continuing unrelated exploration: older actions can leave the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
5. Edit the Title when needed and press Enter: for example `Board: Blocked badge remains after move to In progress`. A found issue can prefill an unchanged Title; keep it unless a rename is intended. Put attempt details in Description.

If the event already left the retained interval, download what remains and describe the gap before making a new attempt. **New recording** clears the current local session and notes.

## Find the deciding evidence

Start with one discrepancy: **what should have changed, and what did you actually see?** Then follow the same subject through the action, sent data, returned data and image. The aim is to show where the evidence first stops matching the expectation and give a developer a useful next check.

The [sample reproduction bundle](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) makes this concrete. The tester expected a card's Blocked badge to clear when it left that lane. All six captured requests returned HTTP 200. Error counts alone would miss the defect.

Download the sample and open `session.md`, `notes.md`, `network.har`, and the three PNGs together. The walkthrough below reconstructs an investigation from those files; it does not claim to recover the author's inspection history. Follow the **bold UI actions** in your own stopped recording and use the sample's observations to see what each comparison accomplishes.

### 1. Establish the subject and the visible discrepancy

Open **Screenshots & Attachments** and select the failure image. Ask whether it identifies both the affected record and the state that makes the result wrong. Pin it while you follow the lead.

In the sample, `003-area.png` shows `QB-DEMO sticky Blocked` with a red badge. It does **not** show the lane heading. Its note says the card is in In progress; that part must be supported by the action/returned data. For your capture, include the card and lane heading in the same image.

Compare the earlier images: `001-area.png` shows this card in Backlog without the badge; `002-full.png` shows it in Blocked with the badge. These establish the starting state and the transition that made the flag relevant. They prevent “this card always had that badge” from becoming an unnoticed assumption.

### 2. Locate the transition that should remove the symptom

1. Open **Actions → Recorded Actions**. In this example, locate **Clicked 'In progress'**, after opening the same card. Select the action and inspect **Target** to confirm the control and subject; use available **What changed**, **Element & form state**, **Page changes**, or **URL changed** when the operation depends on them.
2. Look back at the earlier **Clicked 'Blocked'** action. Add a note there if entering that state is a required precondition. A useful note says why the earlier action belongs in the reproduction, instead of repeating “clicked Blocked.”
3. Expand the In progress action's request-count control, then select the move request. You can also open it from **Related activity** in the action detail. It opens beside the action so you retain the sequence while inspecting the data.
4. In **Payload**, confirm the record ID and requested state. In the sample the move carries ID `3229d3de-fb6d-4196-8f89-f0bf94d63392` and status `in_progress`. Right-click the status field → **Pin**. Read the containing object as well: the move contains ID and status, with no separate `blocked` property.

You do not need to recognize the endpoint name first. The sample uses long generated `/_serverFn/…` paths. Identify the operation by its time and contents. If the request contains only an unfamiliar ID, find the visible card title in a board response, read the ID in that same card object, and use it to follow the move and subsequent reads. Confirm both identity and state; two cards can have similar titles.

This answers “did the browser send the intended lane?” It does not answer “which layer should clear the flag?” The server may be responsible for deriving it. If your payload names the wrong record or state, go back to the action's target and captured input before investigating the returned data.

The sample uses an encoded JSON format with parallel key/value arrays. Find the record by its ID, pair names with values in the same object, and preserve the raw structure. An array position is not a stable record identity across captures. In a large response, use the detail search to locate the ID, then clear it to read neighboring fields; otherwise the comparison itself may be hidden.

### 3. Follow the write into the next read

Open **Response** on the move request. If it only acknowledges the move, it cannot tell you the card's complete resulting state. Use **Open in Network tab** on the related request row to inspect the following board read for the same card. Open **Network** directly if that read has no action association.

Compare three points, not just the final value:

| Sample board read, by request start time (UTC) | Same card's returned status | Raw node paired with `blocked` | What the comparison establishes |
| --- | --- | --- | --- |
| `04:43:38.732` after creation | `backlog` | `{t:2,s:3}` | Baseline value before entering Blocked |
| `04:43:50.465` after the Blocked move | `blocked` | `{t:2,s:2}` | The value changed when the card entered Blocked |
| `04:43:57.141` after the In progress move | `in_progress` | `{t:2,s:2}` | The status changed again, while the blocked node stayed the same |

The sample author interprets those nodes as false → true → true. The raw comparison is independently visible in the HAR; Recorder does not decode arbitrary application formats or prove the server's implementation.

In your recording, right-click the deciding returned value → **Pin**, then mark the sibling status or containing record when needed to preserve identity. In the sample, the Important note targets `response.p.v[0].p.v[2].a[44].p.k[10]`, whose content is the **name** `blocked`. The paired node is in `p.v[10]`; status is the paired field at index 4. A note on the key alone is a useful locator, but read the paired value before claiming what it means.

You now have a narrower finding: the returned card already contains the unchanged blocked representation alongside the new status. That makes the update/read path worth investigating as well as the badge rendering. It does not prove a particular database write, cache, or handler is responsible.

### 4. Try to disprove the explanation before writing it

Open **Timeline** when order could change the conclusion. Check that the move concerns the same card and precedes the read; open the request's **Timing** to check completion before interpreting a later screenshot. A request's Timeline position is its start time. Inspect any intervening action or update that could legitimately change the state again.

Use **Console** when a relevant exception or browser diagnostic offers another explanation. Open the entry and read **Message**, **Stack trace**, source and available arguments; use **Cause** where offered to revisit the associated action. In **Network → Headers**, inspect recorded cancellation, blocking, redirect or cache information if it matters. **Initiator** can give a developer a script-origin lead. These details help test a specific hypothesis; there is no need to collect every warning.

Choose your next move from the evidence:

| What you find | What to inspect next | What to preserve |
| --- | --- | --- |
| The payload sends the wrong ID/value | Action target, captured value and control state; compare with the intended subject | The earliest wrong value and the action that preceded it |
| The intended value is sent, but the returned record is wrong | Earlier state, following read, cache/redirect context and intervening updates | Sent value and returned discrepancy on the same record; leave ownership of the defect open |
| Returned state is correct, but the screen is wrong | Screenshot timing, page reaction, relevant exceptions, and later HTTP/stream updates | Correct returned value and the later incorrect visible state |
| There is no associated request | Broader Network and Timeline, plus action/form state | Whether any matching request was captured; absence of a link is not absence of traffic |
| The decisive value/image is missing or ambiguous | Body-availability reason, capture scope, or a better-framed new attempt | The known observation and exact gap; do not fill it with an assumption |

If the request has a **Trace** badge or recorded correlation headers, preserve the identifier with its request time and method/path. A developer can use it to look for the corresponding backend activity when their services record those identifiers; see [backend correlation](https://fairleadhq.com/docs/recorder/session-correlation/). This can carry the investigation beyond the browser without guessing the server function.

For a live-update issue, inspect **EventStream** or WebSocket messages where present; see the [request detail guide](https://fairleadhq.com/docs/recorder/session-viewer/#read-a-request-as-one-part-of-an-operation). For timing, follow the [responsiveness blueprint](https://fairleadhq.com/docs/recorder/slow-or-unresponsive/).

Stop this investigation when another tab would not change the report's conclusion. If one uncertainty matters, save this attempt and choose one follow-up experiment. For the sample, a new recording of reloading the affected state would test whether the badge/data recur on a fresh read. The sample description mentions earlier Done/reload observations; this particular capture does not establish them.

## Turn useful pins into explanations

Open **Notes**. Your pins now form a short list of evidence to assess without rediscovering it in the full recording. Select each item and use **View evidence** to check the complete source, identity, time and surrounding fields.

For each useful pin, choose **Add comment**; for an existing note, **Edit comment**. Write an observation, its significance, and any limit. Select **Important** for the deciding finding and **Save comment**. A draft is not saved just because you leave the editor. If saving fails, resolve the error while the draft remains available.

The sample's four notes serve different purposes. These are tighter versions of their explanations, not changes to the original files:

| Note location | Why keep it | Example wording |
| --- | --- | --- |
| Earlier Blocked action | Establish the required state before the failure | “After this move, the board read changes the card's blocked node from its baseline representation to `{t:2,s:2}`; the screenshot shows the badge in Blocked.” |
| In progress request payload | Confirm the intended change left the browser | “This move sends the same card ID and `in_progress`. The payload contains no separate blocked property. Which layer should clear it remains to be checked.” |
| Following board response, Important | Identify the decisive data inconsistency | “For this card, status is now `in_progress`, while the raw blocked node is unchanged from the Blocked state. Compare the paired value and status in this object.” |
| Failure screenshot | Connect data investigation to user impact | “The named card still shows the red badge. This crop omits the lane heading; use the preceding move/read for lane context.” |

Avoid “later moves never reset it” when you have inspected only one departure from Blocked. Keep a baseline note if it explains the change; remove speculative or duplicate pins that add no value. **Remove pin** / **Remove note** removes the mark after confirmation; **Delete comment** leaves the pin. **Important** does not reorder the account or set issue priority.

## Assemble the report

Open **Description → Split**. If a found issue offered its description, choose **Add** only when that context belongs in this account; Recorder appends it and does not remove or synchronize it later. Paste and adapt this template:

```markdown
Build / environment / role: [fill in]
Test case / run / attempt: [if applicable]
Preconditions: [setup performed before recording]

### Steps to reproduce
[STEPS]

### Expected
[what should happen]

### Actual
[what happened at the failure point]

### Evidence
[NOTES]

### Scope
[frequency, conditions tried, and missing evidence]
```

1. Select `[STEPS]` in the editable Markdown and choose **Add → Recorded actions**. This local operation inserts the starting page and retained actions into your selection, regardless of Actions filters.
2. Edit the inserted list into the necessary numbered user steps. Remove irrelevant narrative and duplicate clicks from this text; add required pre-Start setup under Preconditions. Editing the description does not delete captured actions or change generated test commands.
3. Select `[NOTES]` and choose **Add → Notes**. Comments and bare pins are inserted with source context. For an image, the text identifies the attachment; attach the image file too.
4. Check **Preview**. Use **Undo** if an insertion landed in the wrong place. If you change source notes afterwards, replace or edit the inserted copy; it does not update automatically.

With a configured connected recording, **Add → Steps to reproduce** requests deterministic steps and **Steps written by AI** requests AI-generated text. Both contact the project Data Plane; the latter sends the full report, while deterministic generation uses a reduced report. Review captured and authored data before generation. The menu displays the reason when unavailable, such as a recording started without sign-in or disabled project storage. Use **Recorded actions** as the local alternative.

Every generation click inserts another result. Review it against the actual attempt before sharing; generated text does not establish steps outside the recording. Description edits save after a pause or leaving the field. Resolve any save error above the editor or on the tab.

## Example: the investigation condensed into a report

This is a suggested rewrite based on the sample, with gaps left visible. Fill in your own build and conditions; do not copy its conclusion onto a different recording.

```markdown
Title: Blocked badge remains after card moves to In progress

Build: not recorded in the supplied sample
Context: Quackban / Pond Redesign; signed-in application session
Recording: 2026-10-07T04:43:24.309Z, 42 seconds
Subject: QB-DEMO sticky Blocked
Card ID: 3229d3de-fb6d-4196-8f89-f0bf94d63392

Steps:
1. Create the card in Backlog (Data Diver, 2 points in this attempt).
2. Open it, move it to Blocked, and close it. The badge is visible.
3. Open the same card, move it to In progress, and close it.
4. Inspect the card's badge.

Expected: leaving Blocked clears the badge.
Actual: the badge remains after the In progress move.

Evidence:
- 001-area.png: this card starts in Backlog without the badge.
- 002-full.png: the card is in Blocked with the badge.
- network.har, POST at 04:43:56.539Z: same ID, status=in_progress.
- Following GET at 04:43:57.141Z: status=in_progress, with the
  blocked node unchanged from the previous Blocked response.
  Raw node: {t:2,s:2}; the sample author interprets it as true.
- 003-area.png: the named card still has the badge. The crop omits
  the lane heading; use the move/read for that context.
- notes.md identifies the marked action, request fields and image.

Investigation finding:
The discrepancy is present in returned card data as well as the
visible badge. Inspect how lane changes update and return blocked
state. This capture does not identify the responsible handler.

Limits / next check:
All six HTTP requests returned 200. Creation bodies are redacted.
Done/reload observations in the original description concern earlier
runs. Capture a separate reload attempt to check the subsequent state.
```

The report's reproduction steps are shorter than the full captured action list. Keep the original technical sequence with the evidence, so the developer can inspect detail without first reading every click. The finding says where to begin and what remains unknown; QA does not need to claim a proven code-level cause to make the report actionable.

## Give each attachment a purpose

| Recipient needs to… | Preserve and cite |
| --- | --- |
| Understand and repeat the failure | Edited description with preconditions, minimal steps and expected/actual; `session.md` for the session context and recorded sequence |
| Follow your reasoning | `notes.md` and finalized notes inserted into the narrative; each comment explains its source's role |
| Inspect the exact sent/returned data | `network.har` with method, request time, record ID and field reference in the narrative; **Copy as HAR** can isolate a selected request when a smaller handoff suffices |
| See the visible discrepancy | The referenced PNGs, including baseline/context when needed; note text alone does not carry image bytes |
| Follow a relevant exception or browser error | The available console output and a precise message/stack/time reference; confirm the file exists |
| Turn the reproduction into a regression check | A reviewed script from **Tests**, plus the expected result that needs assertions and the setup/data requirements |
| Investigate viewer-only evidence | Copy the essential safe measurements or stream excerpts, their source and timestamps into the account before reset |

A saved note excerpt is a pointer into evidence, not a replacement for the complete body. Request URLs in inserted notes identify endpoints; they are not hosted copies of the captured request. The sample's `session.md` links to `console.log`, but no such file is in that ZIP. Check actual files before promising them to the recipient.

## Review and deliver

1. Open **Privacy preview** and inspect the intended export. Review console text, your own prose, and screenshots as well as request data. Apply supported **Redact** controls where needed. The **Originals** display toggle does not select export values.
2. Select **Download** and confirm the files finished in Chrome. Open the title/session-ID folder, inspect `session.md` and available `notes.md`, and check the relevant PNGs. Local downloads include report-excluded images; select the actual reviewed files to share. ZIP them yourself if required.
3. For manual filing, copy the Title and Description into the tracker. Attach the images, `network.har` or console output needed to inspect the claim, and the Markdown summaries.
4. For connected filing, check the selected destination and issue key. Choose **Create issue**, **Update ISSUE-123**, or **Replace description of ISSUE-123** from the send menu. Recorder substitutes the selected key. Picking a menu item does not send until you press the primary button. Keep the fetched Title unless a rename is intended.
5. Open the resulting issue and verify its text and attachments. Issue submission, image attachments, and report storage can have different outcomes. Retry a failed attachment rather than creating the issue again. HAR files are not automatically attached by the screenshot workflow; attach one manually if the developer needs it.

If submission times out, check the tracker before retrying. Preserve your local files and text before **New recording**. The report is ready when the reproduction steps, expected/actual result, and referenced evidence can be followed by the recipient. The [shared workflow guide](https://fairleadhq.com/docs/recorder/testing-workflows/) has additional capture and preservation details.

---

# Reproduce a reported bug
Canonical: https://fairleadhq.com/docs/recorder/bug-reproduction/
Markdown: https://fairleadhq.com/docs/recorder/bug-reproduction.md

Repeat an existing report, follow the same subject from action to request to visible result, and give developers a supported attempt outcome.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: A 12-step reproduction investigation with deeper decision branches: verify targets and misleading labels, compare sent and returned state, pin evidence, explain the outcome, and preserve a developer-ready handoff.

## Prerequisites

- Recorder installed; an existing report and access to its relevant conditions

## Inputs

- Reported symptom, reproduction path, and any original evidence

## Outputs

- An attempt result, source-linked findings, and a supported next step

## Limitations

- Reproducing a symptom does not establish the same root cause; not reproduced does not prove a fix

## Permissions

- Authorization to test the application

## Privacy

- Review evidence and authored notes before sharing

Repeat the reported steps and compare this attempt with the original evidence. Record whether the symptom occurred, where the behavior first differs from the expected result, and what the developer should inspect next. Support the outcome with evidence another person can verify.

**Found a new bug without an existing report?** Start with [Prepare a bug report](https://fairleadhq.com/docs/recorder/bug-reporting/). Already captured this attempt? Start at step 4 below. An original [stored session](https://fairleadhq.com/docs/recorder/stored-sessions/) is reference evidence; make and annotate your own local attempt. Downloaded files do not reopen as an interactive Viewer.

Follow the affected item in your report through **interaction → sent data → returned state → visible result**. Actions, Network, Timeline and Screenshots expose different parts of this chain. Their links let you change perspective while following the same evidence.

<span id="quackban-example"></span>

> **Example references:** the card and Blocked-badge examples below use the [Quackban sample bug report and evidence](https://fairleadhq.com/docs/recorder/testing-workflows/#shared-example-quackban). Follow the procedure with your own recording and expected result.

## Follow this 12-step path

1. **Define the failure.** Read the original report. Write the expected result, reported result, required starting state and observation point. Separate an observed symptom from the reporter's explanation. [Set up the comparison](#set-up-the-comparison).
2. **Prepare this attempt.** Select **Explore**, choose the reported issue, identify A1, record its conditions and check that capture rules cover the path. [Set up the comparison](#set-up-the-comparison).
3. **Record the reported path.** Select **Start recording**, repeat the original interaction, capture the relevant starting and final states, then **Stop recording → Investigate**. Include a reload when the tested path requires a fresh page load. [Capture the transitions](#capture-the-transitions-that-matter).
4. **Verify the actual trigger.** In **Actions → Recorded Actions**, open the relevant action and inspect **Target** and captured state. Confirm the control and subject even if the row's name looks right. [Check the action](#verify-the-trigger-even-when-its-label-looks-right).
5. **Check what left the browser.** Open the action's request count, select the request, then **Payload**. Match the subject ID and requested change; pin the deciding value. [Follow the sent operation](#follow-the-sent-operation).
6. **Check what came back.** Inspect **Response**. Use **Open in Network tab** to find a following read when the write only acknowledges receipt. Compare the same record before and after the trigger. [Compare returned state](#compare-the-same-record-before-and-after).
7. **Reconcile data with the screen.** Open the result in **Screenshots & Attachments**. Use **Timeline** and request **Timing** to check that the image describes the state after completion. Pin the visible result. [Check the observation](#check-the-visible-result-and-its-timing).
8. **Resolve the first unexplained difference.** Follow relevant logs, live updates or condition differences only when they could change your explanation. [Choose the next useful detail](#choose-the-next-useful-detail).
9. **Decide the attempt's result.** Record reproduced, not reproduced, blocked or inconclusive, and state separately how far the technical comparison goes. [Choose a verdict and next check](#decide-the-result-and-the-next-check).
10. **Explain the retained evidence.** In **Notes**, use **View evidence**, then **Add comment → Save comment**. Keep the findings that explain the setup, sent change, returned state and visible impact. [Turn pins into findings](#turn-pins-into-findings).
11. **Write the short account.** Open **Description**. Start with Result, Path, Expected and Actual; add conditions and **Add → Notes** underneath. [Write the attempt summary](#write-the-attempt-summary).
12. **Preserve and verify.** Review **Privacy preview**, download the evidence, update the original issue and verify the text/files at the destination. Only then choose **New recording** for a follow-up. [Deliver the evidence](#deliver-the-evidence-before-starting-again).

## Which “notes” goes where?

| Name | Use it for |
| --- | --- |
| **Pin** / **Note** on evidence | Save a particular action, field, request, log or image. Pin keeps a lead immediately; a comment explains its significance. |
| **Notes** tab | Review those saved marks and return to their sources. This is your evidence collection. |
| **Description** | Write the overall account for local and connected recordings. A found issue can offer its existing description to append; review it before adding. |
| **Add → Notes** | Insert a **copy** of saved comments and bare pins into that account. It does not create new annotations or track later edits. |
| `notes.md` / `session.md` | Downloaded files. `notes.md` contains source annotations; `session.md` contains Description and session context. Older stored reports can contain a separate legacy reproduction-notes value. |

## Set up the comparison

Read the original issue and its evidence side by side. If it includes `notes.md`, follow each note into the supplied request, image or action before adopting its conclusion. A note can contain a useful observation and an untested explanation in the same sentence.

For the [Quackban example](https://fairleadhq.com/docs/recorder/testing-workflows/#shared-example-quackban), write: “After this card enters Blocked and then moves to In progress through Move to lane, close the card and inspect the board. Expected: no Blocked badge. Reported: badge remains.” This is a testable criterion. “The server never clears the flag” is a hypothesis to investigate.

Capture these conditions in your attempt account:

- **Subject and history:** which card or equivalent test record; whether prior entry into Blocked is required.
- **Interaction and observation:** menu versus drag, relevant pace, where and when the result is inspected, and whether reload is part of the reported path.
- **Application context:** build, project, role and relevant settings. Recorder's Environment tab does not supply the application's build or role.
- **Known differences:** missing original build, different permissions, unavailable data, or earlier-run observations that the original recording itself does not cover.

Select **Explore**. For a local attempt, put the issue key and attempt number in the Title and the original issue link in Description. Below, `QB-17` is illustrative and `A1` means the first attempt. For a connected update, select the existing issue and check its key and fetched summary. Recorder can fill an unchanged Title and offer the issue description. Choose **Add** only when appending it helps; the text does not stay synchronized. If lookup fails, read the issue in the tracker and prepare a manual update.

**Prepare backend lookup when relevant.** Connected requests can carry reproduction and per-request correlation identifiers when project configuration enables them and the backend retains them. Preserve an available Trace/correlation value with method, path, time and environment. Account-free recording does not send these headers. See [backend correlation](https://fairleadhq.com/docs/recorder/session-correlation/) for the receipt check; do not invent an ID when it is absent.

**Check capture coverage before Start.** For a connected project, review **Settings → Recording**: **Domain filter**, **Request filter** when shown, **Capture response body for** and **Max response body size**. Page and request coverage can differ: allowing an external API request does not also record interactions on that site's page. Account-free capture follows the starting hostname family and defaults to JSON response bodies with a 512 KiB payload limit; connected project rules can differ. An HTML error page or an excluded SSO step may therefore leave a gap. Resolve required coverage with the project administrator or plan to document the missing evidence; see [capture rules](https://fairleadhq.com/docs/recorder/capture-configuration/).

**Ready to record:** you can name the state you must reach, the observation that decides the result, and any known capture gap. If a missing prerequisite prevents that path, report the blocker or label a narrower check explicitly.

## Capture the transitions that matter

Start recording before any setup that might trigger the defect. Describe earlier setup as a precondition. In the example, preserve three states: before entering Blocked, after entering Blocked, and after leaving it. The middle state matters: no badge at the end means little if the card never acquired one.

If a fresh page load is part of that setup, **Start recording, then reload** to retain the navigation and baseline requests. If the reported bug depends on an already-open page or accumulated state, preserve that attempt first and make reload a separate diagnostic variation.

Use **Capture** for the visible viewport or **Area** for a region. Include the subject and its surrounding context, such as the lane heading. Repeat the reported interaction and capture the result at the reported observation point, including a successful result when the bug does not appear. If reload is part of the claim, preserve both sides of it.

Select **Stop recording**, then **Investigate**, while the decisive events remain in the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention). For a long path, save ordered checkpoints and identify which steps each covers.

**Capture limits:** pre-Start or evicted events cannot be recovered. For a timing-sensitive bug, avoid inserting pauses just to take intermediate images. Preserve the original pace and capture the endpoint; label a slower diagnostic run as a separate attempt.

## Verify the trigger, even when its label looks right

In **Actions → Recorded Actions**, select the trigger and read the preceding setup actions. Open **Target**. Compare **Label** with available **Visible text**, **Aria label**, **Role**, **Selector**, frame and group context. These help distinguish repeated controls and reveal a name borrowed from nearby content.

**Have an ID or error code but no known step?** Enter it in **Search actions, requests, and messages**. **Matches in:** tells you whether the match came from the step, a linked request body or a log. Expand the matching request and open it; when that request matched, the query follows into its detail search. This takes you from business identity to the relevant interaction even with unfamiliar endpoints. Actions searches associated evidence; use Network or Console directly for unassociated traffic/messages, then clear the detail query to inspect surrounding fields.

Use the other details to answer a concrete question:

| Question | Inspect | Decision it helps make |
| --- | --- | --- |
| Did the intended value actually change? | **Captured value**, **What changed** | Continue to the request, or investigate an earlier input/control problem. |
| Was the control able to act? | **Element & form state** | A recorded disabled or invalid state may explain why the expected operation did not start. |
| Did the page take a different path? | **Page changes**, **URL changed** | Check unexpected navigation or context before comparing downstream data. |
| Did keyboard/gesture order matter? | **Event Log**; turn **Key actions only** off for keydown | Reconstruct the relevant events instead of relying on the shorter action narrative. |

In **Page changes**, captured **Appeared** or **Changed from … to …** text can preserve the application's toast or validation message. Quote it with the action context. This text comes from live/alert/status regions in a short observation window, normally 500 ms after a click or 1,500 ms after submit; nearby actions can extend the window. Use a screenshot for slower or uncaptured feedback. **Rage click detected** records repeated clicks, a lead to investigate alongside the response and visible state.

**If the action name and request disagree, preserve the disagreement.** For example, a row might say Blocked while a request for the intended card sends `in_progress`. Verify the target, request time and ID. Use the payload to state what was sent; keep the row name as evidence of a label mismatch. Pin the action and the request value, then explain both in Notes. Do not classify the test as the wrong interaction from the row label alone.

If the label remains confusing, **Rename** can clarify the action narrative after you have documented the original mismatch. It does not correct the captured target or generated test. Avoid deleting the action to tidy the account: that removes evidence and can change associations.

> **Interpretation limit:** request associations can be inferred from nearby events. A contradictory payload may belong to another action. Confirm subject, operation and timing in Network before assigning it. An absent state field also does not mean a recorded `false`.

## Follow the sent operation

Expand the action's request-count control and select a request, or select one in **Related activity**. It opens beside the action sequence, keeping the question “what happened around this interaction?” in view.

1. Read any failure explanation above the request details, then use **Headers** to identify method, destination and time. The explanation distinguishes recorded cancellation, network/CORS blocking, HTTP failure and GraphQL response errors. Preserve it with the visible symptom; a canceled background request alone does not explain the bug.
2. Open **Payload**. Locate the subject ID and requested change. In this example, that is this attempt's card ID and `in_progress`.
3. If the ID is unfamiliar, open a response containing the board, locate the visible card title, and read the ID in that same object. Use the ID from then on; duplicate titles are possible.
4. Right-click the deciding value and choose **Pin**. Inspect the containing operation too. A claim that a property is missing needs the complete relevant object, not a single selected field.

An unfamiliar generated endpoint can still be investigated this way: the subject, payload and time establish what it is doing without requiring QA to know the application's route names.

**If the outgoing ID or value is wrong:** pin it, return to the action, and compare target/input against the intended subject. Your first known discrepancy is already in the sent operation. Investigate that before blaming a later response.

**If the outgoing data is right:** retain it and follow the result. A payload containing ID and status but no blocked flag raises the question of which layer should clear that flag. Check the API expectation with the developer before calling the absent property a client defect.

**If no request is linked:** open Network directly and inspect the surrounding traffic, including live connections where relevant. Unassociated/background requests may still be present. A missing action link is a navigation gap, not evidence that the browser sent nothing.

## Compare the same record before and after

Open **Response** on the write. Does it return the changed record, an application error, or only an acknowledgement? A **GraphQL: … errors in response** badge can flag an HTTP-200 failure; inspect the returned error details. For GraphQL reports, **Network → More filters → GraphQL → With errors** helps locate those responses. When the application reads the updated data separately, follow that read.

Use the request row's **Open in Network tab** arrow. You now see session-wide traffic, which can reveal the following board read, a retry or another update outside the original action's request group. Select the relevant read, open Response, and locate the same card by ID. Check identity, new status and the field connected to the symptom together.

The [Quackban example](https://fairleadhq.com/docs/recorder/testing-workflows/#shared-example-quackban) compares these three points. For your bug, identify the equivalent baseline, prerequisite and reported failure point:

| Point | Question |
| --- | --- |
| Before the prerequisite | Was the subject initially in the expected baseline state? |
| After entering Blocked | Did the prerequisite actually create the state that must later be cleared? |
| After moving to In progress | Did status change, and did the blocked-related state change as expected? |

Pin the deciding value or smallest useful containing object. A pin on a key name does not necessarily preserve its value or siblings. Reopen the containing record and check the saved context. If a detail search hides sibling fields, clear it before comparing identity and state. Before claiming a property is absent, check the body's completeness: **Privacy preview → Not sanitized → Truncated bodies** lists affected requests. A truncation marker in the body is also an evidence gap, not the server's content.

**Move between details without losing the comparison.** The viewer header's **Back** and **Forward** restore the selected record, request subtab, scroll and opened JSON branches. Use them to alternate between the outgoing value and following response. Clicking a main tab opens its list. The request subtab also carries across requests, so once Response is selected you can inspect consecutive reads there. Check the request heading each time. **Cause**, where available, returns to an associated action; verify that lead as you would any other association.

**If the returned record is already wrong:** compare it with the earlier read and any intervening update. You have narrowed the discrepancy to the captured update/read sequence.

**If it is correct:** move to the visible result and look for a later update or display problem. Both branches need the screenshot and timing comparison below.

**Evidence limits:** unavailable, redacted or truncated bodies constrain this comparison; keep the displayed reason. If the baseline read happened before Start, record that gap and include the relevant load/setup in a follow-up if needed. Encoded values need the application's format to interpret them; preserve the raw observation if meaning is uncertain. Viewer history clears on reload; pins are the landmarks for later review.

## Check the visible result and its timing

Open **Screenshots & Attachments**, select the result image, and verify the subject, destination context and symptom. Pin the image. An image can establish a visible badge while omitting the lane heading; then the lane needs separate supporting evidence.

An action's screenshot control opens linked captures. Recorder associates a viewport/area capture with the nearest eligible preceding action within five seconds; that may be closing the card, rather than the earlier move. Capture when the deciding state is visible, then verify the link and timing. The association window is a navigation aid, not the application's response-time requirement.

Open **Timeline** to inspect what happened between the trigger and image. Select the request and inspect **Timing** for completion. A request appears in Timeline at its **start**: an image listed after it might still precede its response. Check for another move, retry, navigation or live update before the image.

The useful chain is: intended move → relevant read completes → image shows the result for that subject. If the image predates completion, preserve what it shows and identify the later observation needed to distinguish a temporary state from the reported failure. If the original requirement defines a response-time limit, compare against it; otherwise do not invent an arbitrary wait as the pass criterion.

**Checkpoint:** can you state separately what was returned and what was visible, at the relevant point? A matching screenshot with unavailable diagnostics can still reproduce the symptom. A mismatched or poorly timed image may leave that criterion inconclusive.

## Choose the next useful detail

Investigate the earliest unexplained difference. Open another view when it can distinguish competing explanations:

| What you found | Where to go and what to compare | Useful next decision |
| --- | --- | --- |
| Returned state contains the discrepancy | Earlier/following responses, intervening writes, **Headers** for relevant cache information | Which update or read first differs from the expected transition? |
| Returned state is correct but the later screen is wrong | **Console**: Message, Stack trace, source and available arguments near the update | Is there a relevant exception or failed UI update to give the developer? |
| State changes again after the read | Captured **EventStream** or WebSocket messages: subject, changed value and time | Did a live update replace the state you first inspected? |
| Equivalent attempts send different operations | Targets/payloads, relevant **Headers** and **Cookies**, then **Environment** | Is role/session/browser context a condition worth controlling in the next attempt? |
| The delay itself changes the outcome | Request **Timing** and relevant Timeline performance/lifecycle details | Is the image early, a request slow, or later page work delaying the visible state? |
| The developer needs a code/backend lead | **Initiator**, the request's **Trace: …** badge and available correlation headers | Copy Trace using its badge; preserve the relevant request headers and reproduction ID with operation, time and environment. |
| A repeatable automated check would help | **Tests**, highlighted script lines or **Review locator** | Identify setup/locator work and the missing assertion, such as “badge absent after leaving Blocked.” |
| A successful image response looks wrong or stale | **Response → Load from cache**, when offered, then **Add as attachment** if useful | Compare the retrieved image with the screenshot. Record that it was loaded later; cache lookup or **Re-download image** does not certify the original bytes. |

Pin relevant log messages or stack fields. **Console → Source: Browser** helps isolate browser diagnostics such as CORS messages; keep the exact message and time. Explain the connection to this operation. A request's **Served from …** line can identify recorded cache/service-worker use when stale state is plausible. Retain the **inferred** qualification on an Initiator lead.

Environment records browser and initial page conditions. For layout or timing differences, inspect Timeline's viewport resize, visibility and back/forward-cache events, and recorded browser-zoom actions. A long task can explain a delayed reaction; initial document-load timing does not measure a later move. Copy useful safe facts/time from Environment, standalone performance/lifecycle details or WebSocket messages into the account where source-note controls are unavailable.

**Scope limit:** Tests previews/exports do not execute the reproduction or add the business assertion automatically. Reviewing every tab is unnecessary once the evidence supports an outcome and useful next check.

## Decide the result and the next check

Keep the **symptom verdict** separate from the **diagnostic finding**:

| What the attempt establishes | Result | Preserve / do next |
| --- | --- | --- |
| Reported path reaches the same visible failure | **Reproduced** | State whether sent/returned data also matches, differs, or could not be compared. |
| Reported path completes and the expected state is positively observed | **Not reproduced under these conditions** | Save that successful state and identify the first meaningful difference from the original. |
| A missing prerequisite or earlier failure prevents the observation point | **Blocked** | Record the last reached step and evidence of the blocker. The reported transition remains untested. |
| Decisive observation is missing or ambiguous | **Inconclusive** | Name the one observation needed to settle it. |

Before settling the result, use **Actions → Issues · N** or **Needs attention** for a quick check of related failures and error logs, and **Overview → Review checklist** for session-wide leads. These flags do not determine the verdict. If a required action is missing, inspect Timeline for **Recorder injection failed** and check capture scope/retention. A capture gap cannot establish that the user never performed the action; preserve the gap and choose the outcome your remaining evidence supports.

For a non-reproduction, work backwards: did the card actually enter Blocked? Was the same move method used? Did the outgoing operation match? Did the returned value clear when the original retained it? Or did the returned state match while the screen differed? Each answer places the first known difference at a different point in the chain.

Choose one follow-up question before starting A2. If prior history may matter, compare a fresh direct move with the original Backlog → Blocked → In progress path. If persistence is unresolved, preserve A1, then record a fresh read after reload. If role differs, repeat with the reported role and equivalent setup. Keep other known conditions alike and explain unavoidable differences.

For intermittent behavior, keep successful and failing attempts. Compare their earliest different state, operation or timing. A not-reproduced attempt does not prove a fix; a reproduced symptom does not establish the same root cause. Stop when you can state the result, strongest finding and next useful check. QA need not identify the faulty handler to deliver valuable evidence.

## Turn pins into findings

Open **Notes**. Treat the saved pins as a review queue, not a finished report.

To keep the original screenshot beside this attempt's evidence collection, optionally use **Screenshots & Attachments → Upload image** or **Paste image** in the local Viewer after stopping. Add an image note such as “Reporter-supplied image from QB-17; original capture time unknown; reference only.” Its attachment time is when it was added, and it is not linked to an action in A1. Open each image through **Notes → View evidence** to compare them; check report inclusion for an image added outside the recorded period.

1. Select a pin and **View evidence**. Recheck identity, value, timing and surrounding context.
2. Return to Notes, select **Add comment**, and write **what is observed → why it matters → what remains open**. If the explanation is already clear at the source, its **Note** control opens the editor directly.
3. Mark the deciding finding **Important**, then **Save comment**. Closing the editor does not save its draft. Important highlights evidence; it does not set issue priority.
4. Remove duplicate or unsupported leads. **Delete comment** keeps the pin; **Remove pin** or **Remove note** removes the mark after confirmation.

For an attempt reproducing the [Quackban badge discrepancy](https://fairleadhq.com/docs/recorder/testing-workflows/#shared-example-quackban), useful comments have different jobs:

| Source | Example comment to adapt to verified evidence |
| --- | --- |
| Prerequisite action and supporting state | “A1 entered Blocked before the departure. The following read/image establishes the state that this test expects to clear.” |
| Outgoing destination value | “This operation sends the intended card ID and `in_progress`. The original action row says Blocked; Target and timing support a label mismatch. Preserve both when interpreting the steps.” |
| Deciding response value/object | “The following read returns this card in In progress while its blocked-related value remains unchanged from the Blocked read. The first observed inconsistency is in returned state; flag-clearing ownership remains open.” |
| Final screenshot | “This image shows the badge still present at the reported observation point. Expected: absent after leaving Blocked. The lane and completion timing are established by [the evidence actually available].” |

Use the mismatch comment only if there is a mismatch in your attempt. For a non-reproduction, preserve positive evidence instead: “Same prior Blocked state; this later image shows the badge absent after the move,” with the corresponding returned-state observation on its own source.

**Note limits:** excerpts are bounded and may omit nearby fields; include the full HTTP Archive (HAR) of captured requests and responses when needed. Comments are saved as written, so check your own text for sensitive data. Later insertion into the summary makes a copy, not a live link to edited wording.

## Write the attempt summary

Open **Description** and choose **Split** to edit and preview together. Put the outcome first. This opening illustrates the [Quackban case](https://fairleadhq.com/docs/recorder/testing-workflows/#shared-example-quackban); replace the example issue key, path and result with your own:

```markdown
Result: QB-17 / A1: reproduced.
Path: Backlog → Blocked → In progress, using Move to lane; inspect board.
Expected: Blocked badge disappears after leaving Blocked.
Actual: Badge remains on the same card at the reported observation point.
```

Below it add the tested build/role/subject, known differences, strongest technical finding and next check. For example: “The intended status was sent; the following read changed status but retained the blocked-related value. Original build is unknown. Developer next check: how the move handler and subsequent read derive that value.” Change this account when the evidence differs.

For backend handoff, add the reproduction ID and the deciding request's available Trace/correlation ID with its method, URL/path, timestamp and environment. If an ID was not captured or backend receipt is unverified, say so and retain the request context. IDs help locate server evidence; they are not required to establish every visible reproduction.

Insert your evidence beneath that explanation:

1. Type and select `[EVIDENCE]`, then choose **Add → Notes**. Recorder inserts saved comments **and bare pins**, with their source context. Finish comments first so the recipient does not receive unexplained bookmarks.
2. If the path needs detail, use **Add → Recorded actions** in another selected placeholder. Edit the inserted copy into the meaningful steps and add pre-Start setup explicitly. Check misleading action names against the evidence. Actions filters do not limit this insertion.
3. Check Preview. Without editor focus/selection, insertion appends a headed block. Use **Undo** if it lands in the wrong place. Description saves after a pause or leaving the field; resolve any save error before continuing.

**Optional writing assistance:** when enabled, **Add → Steps to reproduce**, **Steps written by AI**, and **Improve → Rewrite with AI** use a configured service. Review privacy before using them and check their output against the captured path; generation can reorganize text but cannot decide the verdict for you. A recording started without sign-in does not become eligible for generation by signing in afterwards. Local Recorded actions and Notes insertion remain useful without generation.

Update the Title only when an intentional rename helps. For an existing issue, keep the fetched Title and put A1/result in Description. Explore has no Recorder result selector. Writing the reproduction outcome does not set a test-management result; use [test outcomes](https://fairleadhq.com/docs/recorder/test-outcomes/) when required.

## Deliver the evidence before starting again

The recipient needs the **short attempt account, source comments, relevant images and captured requests/responses**. For a focused developer check, select the deciding request and use **Copy as cURL** or **Copy as HAR** after privacy review. The latter copies a one-request HAR document; save and attach it manually if useful. Keep the complete capture when the finding depends on earlier/following requests. See [copy and reproduce a request](https://fairleadhq.com/docs/recorder/developers/reproduce-a-request/) for adapting credentials, destination and state before replay.

If replaying the UI path helps, include `steps.json` for [Chrome DevTools Recorder](https://fairleadhq.com/docs/recorder/developers/devtools-export/), or a script from Tests. Supply login/data setup and the expected-result assertion. Keyboard, paste and drop events are not directly exported as replay steps; inspect whether subsequent supported input/submit events cover the intended interaction and fill remaining gaps.

Review **Privacy preview**, captured values, images and authored text before sharing or using remote writing assistance. **Originals** changes local display/search; export choices are separate. Apply the supported review decisions, then select **Download**. Confirm completion in Chrome and open the actual folder.

| Deliverable | What to check before handoff |
| --- | --- |
| Attempt summary | Result/path/expected/actual first; conditions, comparison and next check underneath. |
| `session.md` and `notes.md` | Description/session context and saved annotations match what you intend to share. Notes identify sources; endpoint links do not host captured responses. |
| `network.har` | The relevant operation and following reads are present. Cite method, time, subject ID and field so the developer can find the comparison. |
| Referenced screenshots | Actual files show the claimed subject/state with sufficient context. |
| Relevant logs or copied observations | The precise message/value/time used by your finding survives in the handoff. |

> **Delivery limits:** the standard local files omit WebSocket frames and dedicated browser-diagnostic, performance or lifecycle files. The downloaded HAR also omits recorded timing phases and initiator stacks; **Copy as HAR** retains available timing phases for the selected request. Preserve decisive measurements, script-origin details and IDs in the account or an available stored report. Local downloads can include screenshots excluded from the report, so review the actual files. Tracker screenshot submission does not automatically attach either HAR; attach reviewed files manually.

For a manual update, paste the attempt account into the original issue and attach the reviewed evidence. For a configured connected update, verify the issue key and choose **Update ISSUE-123** or **Replace description of ISSUE-123** from the send menu; Recorder substitutes the selected key. Selecting an item changes the primary action; nothing is sent until you press it. [Issue submission](https://fairleadhq.com/docs/recorder/issue-trackers/) explains the choices.

Open the destination and verify text and attachments. Issue update, image attachment and report storage have independent outcomes. Retry a failed attachment through its retry control when available. After a timeout, check whether the update already landed before submitting again. For file failures, use [download recovery](https://fairleadhq.com/docs/recorder/troubleshooting-exports/).

Only after the attempt is preserved, return to the application, open Recorder's side panel and select **New recording**. Reset clears local evidence and notes. Label the next attempt A2, record its changed condition, and retain A1 separately. When a candidate fix is ready, continue with [Verify a bug fix](https://fairleadhq.com/docs/recorder/fix-verification/).

## Worked example: read the supplied bundle

This section interprets the [Quackban sample reproduction bundle](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) for **Blocked tag stays after card leaves the Blocked lane**. Start with its `session.md` bug report and `notes.md` evidence comments. Its filenames and encoded values belong to that capture; they are not instructions to find the same positions in your own recording.

The bundle follows one card through Backlog → Blocked → In progress. All six HTTP responses are 200. Compare the board reads for the **same card ID**:

| Stage in the sample | Returned state | Visible evidence |
| --- | --- | --- |
| After creation | `status: backlog`; node paired with `blocked`: `{t:2,s:3}` | `001-area.png`: card in Backlog, no badge |
| After entering Blocked | `status: blocked`; node changes to `{t:2,s:2}` | `002-full.png`: card in Blocked, badge present |
| After leaving Blocked | `status: in_progress`; node remains `{t:2,s:2}` | `003-area.png`: card still has the badge; crop omits lane heading |

In this encoded response, `p.k` holds keys and `p.v` their paired values. The saved Important note targets the `blocked` key at `p.k[10]`; inspect `p.v[10]` and the same object's status/identity to understand it. The card's array position `a[44]` is incidental. The author interprets the nodes as false → true → true; without the application's serializer contract, the directly verifiable finding is the node changing on entry and remaining unchanged on departure. Recorder does not provide a universal decoder for these numbers.

Read the four notes as an argument: **Blocked action establishes the prerequisite; outgoing `in_progress` establishes sent intent; following response establishes retained state; image establishes visible impact.** Each contributes a different fact. The payload's lack of a separate blocked property leaves open who should clear it. The final crop needs other evidence for its lane. The description's Done/reload observations refer to earlier runs, so they do not extend this recording's tested path.

A supported conclusion is that the reported visible symptom and the returned-state discrepancy occur together in this captured transition. A useful next check is how the update/read path derives the blocked-related value, followed by a separate persistence check if needed. That is enough to direct developer investigation without claiming the exact faulty code is already proved.

[Choose another testing workflow](https://fairleadhq.com/docs/recorder/testing-workflows/).

---

# Download session artifacts
Canonical: https://fairleadhq.com/docs/recorder/bundle-contents/
Markdown: https://fairleadhq.com/docs/recorder/bundle-contents.md

Save reviewed browser evidence to your computer.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Save reviewed browser evidence to your computer. Files depend on available evidence; downloads are a folder, not a ZIP or full viewer export.

## Prerequisites

- A stopped recording available in this browser

## Inputs

- Reviewed recorded evidence

## Outputs

- A local folder of selected evidence files

## Limitations

- Files depend on available evidence; downloads are a folder, not a ZIP or full viewer export

## Permissions

- Chrome download access

## Privacy

- Review captured content before sharing

Download a stopped recording from this browser as a folder of files. This works for account-free and connected recordings; it is not available for a stored session opened from Control Plane. You can share selected files through your team's normal issue or test-management workflow.

## Download the local recording

1. Stop recording and select **Investigate** to review the evidence.
2. Edit the title field in the viewer header to name the evidence by case or checkpoint. Press Enter or leave the field to save.
3. Select **Download** in the viewer header.
4. Check Chrome's downloads to confirm the files finished saving.

For an account-free recording, you can also reopen the side panel from the toolbar and select **Download report**. Both download controls start saving immediately, without an additional privacy acknowledgement. Review the evidence first. Connected recordings use the viewer download.

If you add or change attachments after opening the viewer, reload the viewer before downloading so it has the latest attachment snapshot.

Files are saved under a folder based on the session title and identifier. The local download writes individual files, not a ZIP archive, and does not submit an issue or upload the recording.

## Choose the files to share

| File | Purpose |
| --- | --- |
| `session.md` | Title, written description, session context, numbered actions, evidence counts, and artifact links |
| `notes.md` | Saved notes and pins grouped by source; omitted when there are none |
| `network.har` | Captured HTTP requests and available response content in HAR format |
| `console.log` | Captured console messages and stack traces |
| `steps.json` | Actions in Chrome DevTools Recorder format |
| `playwright.spec.ts` | Generated Playwright starter test |
| `puppeteer.js` | Generated Puppeteer starter script |
| `screenshots/*.png` | Available screenshot and image attachments |

Files depend on available evidence. Images are present only when added. Downloads include attachments marked **Exclude from report** or **Outside recorded period**. Review the screenshot folder itself and share only the intended images. WebSocket frames and every viewer diagnostic panel are not included in these standard artifacts.

Generated scripts need safe test data, stable locators, setup, and assertions. See [Turn a recording into a reliable automated test](https://fairleadhq.com/docs/recorder/developers/reliable-automated-tests/).

## Session summary and notes

Open `session.md` first. It contains the resolved title, your description, start time, elapsed duration, browser, starting page, numbered recorded actions, evidence counts, and links to the prepared artifacts. Write the expected result, actual result, build, and test conditions in **Description** before downloading; Recorder does not infer these from captured activity. `notes.md` contains source-linked annotations. Older stored reports can contain a separate legacy reproduction-notes value that is not part of the current local Description editor.

`notes.md` contains saved source-linked annotations, including pins without comments. Entries are grouped by their source and include available field paths, context excerpts, importance markers, and your text. A pin without text reads “Marked without a comment.” With no saved notes or pins, the file is omitted. Notes and descriptions remain authored content that needs privacy review.

In the [real sample](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle), `session.md` records a 42-second attempt with 21 numbered action rows and three screenshots. `notes.md` has four observations: the move into Blocked, the request moving to In progress, the following board response, and the cropped screenshot. Read them alongside `network.har`; a note's explanation is the tester's interpretation, not an automatic diagnosis.

The sample summary links to `console.log`, but the ZIP contains no such file. Check the files actually present before sending the folder. A zero console-error count does not establish that there were no messages or that the test passed.

Downloads generate text artifacts afresh from the session and its saved review decisions. If you change the description, notes, or supported privacy decisions, download again and inspect the replacement files. A retry uses the same folder and overwrites matching filenames; it does not recall copies already shared.

## Recover a partial download

If Recorder reports that some files failed to download, keep the session and retry the same download control. A partial failure does not clear the recording. Check the resulting files; starting a download does not guarantee that Chrome finished writing it.

Do not select **New recording** until you have the evidence you need.

## Review before sharing

Console text, screenshots, and manually written observations can contain secrets or personal data. Automatic redaction is not universal. Follow [Review data before sharing](https://fairleadhq.com/docs/recorder/review-redaction/).

Explore a real reproduction in the website's [sample bundle](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle). Its local artifacts have been packaged as a ZIP for download from the website.

---

# Understand capture rules
Canonical: https://fairleadhq.com/docs/recorder/capture-configuration/
Markdown: https://fairleadhq.com/docs/recorder/capture-configuration.md

Understand why scope, payload limits, and redaction rules affect recorded evidence.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Understand why scope, payload limits, and redaction rules affect recorded evidence. Project sensitive-key lists replace the local baseline; rule changes do not repair shared evidence.

## Prerequisites

- An application check and its recording context

## Inputs

- Required domains and data-handling rules

## Outputs

- Capture gaps identified for the project administrator

## Limitations

- Project sensitive-key lists replace the local baseline; rule changes do not repair shared evidence

## Permissions

- Access to the recording

## Privacy

- Review content and destination before sharing

Recorder applies the settings selected when recording starts. Account-free recording uses built-in rules; connected recording uses the assigned project's rules. This guide explains their effect on evidence. Control Plane setup is outside this guide.

## Check page and network scope

Account-free recording derives its scope from the starting hostname family, with a leading `www.` normalized. Connected projects can have separate page and network rules. If an expected request is missing, first clear Network filters, then check its domain and whether it occurred inside the [retained interval](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).

Give the project administrator the missing URL, recording time, and selected project when a rule needs investigation. Capture scope does not restrict connected correlation-header destinations; see [backend correlation](https://fairleadhq.com/docs/recorder/session-correlation/).

## Recognize body limits

Payload size and content-type rules affect which bodies are retained. The account-free default size limit is 512 KiB. A missing or truncated response is not proof that the server returned no data, and increasing a future limit cannot restore bytes absent from this recording.

Read the reason in [Network](https://fairleadhq.com/docs/recorder/network/) and identify the affected request in your handoff.

## Understand excluded elements and frames

Excluded selectors suppress matching DOM capture. They do not obscure pixels in a screenshot. Untrusted iframe input values may be unavailable even when an interaction was captured; a missing value does not mean the tester left the field blank.

Use [navigation and frame guidance](https://fairleadhq.com/docs/recorder/navigation-and-frames/) to explain these gaps. Review images separately.

## Review sensitive values

Project sensitive-key lists replace the account-free baseline. Always-on password/passwd/secret matching remains. Supported manual redactions affect reviewed exports; including automatically hidden originals depends on the session's reveal policy.

Read [How redaction works](https://fairleadhq.com/docs/recorder/redaction-rules/) and inspect the evidence before sharing. If your team changes project settings, preserve the existing session and start a new recording to check their effect. Existing downloads and submitted reports are separate copies.

---

# What Recorder captures
Canonical: https://fairleadhq.com/docs/recorder/captured-data/
Markdown: https://fairleadhq.com/docs/recorder/captured-data.md

Understand the evidence available for a browser test.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Understand the evidence available for a browser test. Viewer and download coverage differ; the retained timeline is bounded.

## Prerequisites

- Recorder installed

## Inputs

- A planned browser check

## Outputs

- An understanding of available evidence

## Limitations

- Viewer and download coverage differ; the retained timeline is bounded

## Permissions

- Website access and browser debugging for capture

## Privacy

- Review captured content before sharing

Recorder captures browser evidence after you start recording. The [retained-timeline limit](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) determines which timeline events remain at Stop.

## Actions and page changes

Captured actions include supported clicks, input changes, keyboard actions, scrolling, and navigation, including SPA URL changes. Labels, selectors, and available DOM/state changes help explain the sequence.

Capture is not a video or complete replay of every page state. Sensitive inputs, untrusted frames, and inaccessible components can limit action detail. See [Recorded actions and user steps](https://fairleadhq.com/docs/recorder/steps-and-events/).

## Requests and diagnostic messages

Network evidence includes captured requests, responses, headers, payloads, timing, and available initiator information. GraphQL and supported streaming traffic have additional viewer evidence. Bodies may be unavailable, redacted, or truncated.

Console output, JavaScript exceptions, and browser messages help explain failures. Capture scope and browser availability affect what is present. See [Network](https://fairleadhq.com/docs/recorder/network/) and [Console](https://fairleadhq.com/docs/recorder/console/).

## Images and annotations

You can take viewport or area screenshots and attach images from the clipboard or a file. Screenshots are explicit captures, not automatic images for every step. Clicked images can also have a small captured thumbnail in action details. Privacy preview reports those thumbnails under **Not sanitized → Screenshots**, but cannot hide them; inspect the action and repeat with safe content when needed.

Add notes to relevant evidence in the local viewer. Save essential observations as notes and include `notes.md` in your handoff; check [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes). Images and notes require manual privacy review.

## Environment and performance

Browser/page context, lifecycle events, FCP/LCP observations, long tasks, and selected resource timings can support an investigation. Performance measurements may include buffered entries from before Start; they do not supply pre-Start action history.

Recorder does not provide a complete Core Web Vitals profiler, accessibility scanner, or automatic test verdict.

## Match evidence to the handoff

The viewer and [download folder](https://fairleadhq.com/docs/recorder/bundle-contents/) have different coverage. A HAR contains HTTP evidence, not all viewer diagnostics. WebSocket frames are viewer evidence and are not included in the standard download bundle.

See [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes). Keep build, environment, expected and actual behavior, and your result in a separate execution summary. Consult [Capture support and limits](https://fairleadhq.com/docs/recorder/developers/capture-support/) for technical boundaries.

---

# Console and browser errors
Canonical: https://fairleadhq.com/docs/recorder/console/
Markdown: https://fairleadhq.com/docs/recorder/console.md

Inspect messages, exceptions, and their place in the recorded sequence.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Inspect messages, exceptions, and their place in the recorded sequence. A clean console does not prove a passed test; console text needs manual privacy review.

## Prerequisites

- A recorded session open in the viewer

## Inputs

- Console messages and browser errors

## Outputs

- Messages linked to the observed behavior

## Limitations

- A clean console does not prove a passed test; console text needs manual privacy review

## Permissions

- Access to the session

## Privacy

- Review captured content before sharing

Use **Console** to inspect messages and errors captured during the retained interval. Combine them with the visible result and relevant requests.

## Find relevant messages

1. Open the [session viewer](https://fairleadhq.com/docs/recorder/session-viewer/).
2. Select **Console**.
3. Narrow the entries by **Level** or **Source**.
4. Select a message to inspect its details.

Opening Console from the Overview issue summary preselects errors and warnings. Change **Level** to see other messages if entries seem missing.

Review the message text, available exception details, and stack trace. Compare absolute timestamps and elapsed times with the action you are investigating. Source filters distinguish different origins of diagnostic messages; do not assume every entry came from the application code you own.

## Trace the context

Follow an available action association to inspect nearby behavior. It is an inferred timing relationship, not proof of causation. Compare related [network traffic](https://fairleadhq.com/docs/recorder/network/) to determine whether an error accompanies a failed request or another event.

For application console entries and browser logs with stable entry identifiers, add a [source-linked note](https://fairleadhq.com/docs/recorder/notes/) with what you observed and why the message matters. Include uncertainty where the stack or context is incomplete.

## Share useful evidence

The local download includes captured console content in `console.log` when available. Review it before sharing: console messages have no automatic secret matching and may contain credentials, personal data, or application payloads. In a local session, use **Redact** on an entry, message, stack trace, or supported argument; saved choices apply to the report and `console.log`. Check the exported file after making changes.

Include the expected and actual result with the relevant timestamps. A list of errors without the triggering conditions is often insufficient to reproduce the problem.

## Interpret an empty console

Check filters first. The absence of a message may reflect the retained interval, capture availability, or the application never emitting that message. The [real sample](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) reports zero console errors and contains no console log, yet records a visible badge defect. A clean console does not prove the test passed. Use [Record test outcomes](https://fairleadhq.com/docs/recorder/test-outcomes/) to assess the actual acceptance criteria.

---

# Recorder for developers
Canonical: https://fairleadhq.com/docs/recorder/developers/
Markdown: https://fairleadhq.com/docs/recorder/developers.md

Investigate a reported failure using the issue description and shared browser evidence.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Use session summaries, HAR requests, console logs, screenshots, and action exports to trace a reported failure and verify a fix.

## Prerequisites

- Access to the issue description and supplied evidence

## Inputs

- Expected and observed behavior, reproduction context, and available attachments or links

## Outputs

- An evidence-backed diagnosis, a regression test, or verification steps for QA

## Limitations

- An issue does not necessarily include every downloaded artifact
- Recorded associations do not prove causality
- Generated scripts need setup and assertions
- Backend correlation needs identifiers captured and logged in the target environment

## Permissions

- Access to the evidence and any application logs used
- Authorization to replay requests or tests against the chosen environment

## Privacy

- Review request data, logs, images, and notes before replaying or sharing them

Use the issue description and files shared from Recorder to investigate a reported failure. Start by comparing what the tester expected with what actually happened. Then use the recorded actions, network requests, console logs, and screenshots to identify the application code to inspect.

Investigate downloaded artifacts with your editor, browser developer tools, existing test tools, and AI Agents.

## Start with the real sample

Download the [sample bug report ZIP](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip) and unzip it. It records **Blocked tag stays after card leaves the Blocked lane** in [Quackban](https://fairleadhq.com/docs/recorder/schema/#about-quackban-and-credits): the tester creates `QB-DEMO sticky Blocked`, moves it into Blocked, then into In progress. The expected result is that leaving Blocked clears the tag; the reported result is that the tag remains.

Read `session.md` first, then `notes.md`, `network.har`, and the screenshots. The [bundle structure](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) lists the exact files. Follow the [worked investigation](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#worked-example-the-sticky-blocked-tag) to connect the recorded action to its request and returned state without installing Recorder or replaying the session.

## Choose the evidence for your question

Use the artifacts shared with the issue:

| Investigation question | Start with | What it helps you establish |
| --- | --- | --- |
| What did the tester do? | `session.md` and `notes.md` | The session context, action sequence, and QA’s observations. Notes are included when the session contains them. |
| What did the application send and receive? | `network.har` | Request URLs, methods, headers, payloads, response status, and captured response content. |
| Where did the browser code fail? | `console.log` | Error messages and stack traces to follow into application code. |
| What did the user see? | Screenshots | The visible state to compare with the expected result and network response. |
| How can I repeat the interaction? | `playwright.spec.ts`, `puppeteer.js`, or `steps.json` | Recorded actions to run in your test environment and develop into a regression test. |

## Reconstruct the attempt

Open `session.md` in a Markdown viewer or editor. Read the description, starting page, browser, and numbered actions alongside the tracker issue. Use `notes.md` for QA’s observations and screenshots for the visible result.

Find the action associated with the reported failure. Its elapsed time is relative to the session’s start time. Use that point to locate the corresponding requests and console entries. Keep the action, request, and visible result together as you investigate.

## Inspect the request and response

Open `network.har` in a HAR viewer, or inspect its JSON in your editor. Locate the relevant request by endpoint, method, and time; then inspect:

1. **Request data:** compare the query parameters and payload with the action and expected application state.
2. **Response:** read the status and captured body to see what the service returned. For GraphQL, inspect operation errors as well as HTTP status.
3. **Application handling:** compare that response with console output and the screenshot. Follow the corresponding request handler or state update in application code.

This helps narrow the investigation: whether the browser sent the intended input, the service returned the expected result, and the UI handled it correctly.

To test a request separately, transfer its method, URL, and relevant payload into your HTTP tooling. Use credentials and data for your chosen test environment, then compare the new response with the captured one. Redacted values need appropriate test values.

## Follow errors into code

Open `console.log` and search around the relevant action or request time. Read the error message and stack together, then follow the referenced code in the application build used for the attempt.

Compare the code’s assumptions with the captured request and response. For example, an exception while reading a response property gives you a specific question: did the service return that property, and does the client handle the returned shape?

Use surrounding log entries to understand the sequence. Check the suspected cause against the evidence before treating a nearby error as the explanation.

## Connect the browser request to server logs

When the evidence contains a correlation identifier that your application logs, search for it in the relevant environment. Match the request URL and time, then follow the server-side processing and error details.

[Backend correlation](https://fairleadhq.com/docs/recorder/session-correlation/) explains the connected-project setup and identifiers. Correlation headers must have been sent and logged for this route to connect the captured browser request to a server log entry.

## Example: a failure with successful requests

The sample contains six HTTP requests, all returning 200. Its summary reports zero console errors, and there is no `console.log` in the ZIP. The bug is in the application state and visible result, so filtering for failed requests would miss it.

| Evidence | Observation | Next investigation step |
| --- | --- | --- |
| `session.md` | Action 20 selects In progress at +32.226 seconds. | Find the move request just after that action. |
| `network.har` | The POST at `04:43:56.539Z` sends the card ID and `status: "in_progress"`, with no `blocked` field. | Inspect the lane-change handler and its state-update rules. |
| `network.har` and `notes.md` | The following board response has `status: "in_progress"`; the blocked value remains the same as after entering Blocked, which QA identifies as `true`. | Compare the response fields with the agreed rule for clearing the flag. |
| `screenshots/003-area.png` | The card still has a red Blocked badge. The crop does not include the lane heading. | Use the action and response to establish the lane, and the image to establish the visible badge. |

This narrows the investigation to how lane changes and the blocked flag interact. It does not establish which application function needs changing. The [detailed walkthrough](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#worked-example-the-sticky-blocked-tag) includes exact HAR paths and a local inspection command.

## Turn the recorded actions into a regression test

Open the supplied Playwright or Puppeteer script in your test project, or import `steps.json` into Chrome DevTools Recorder. Review the recorded sequence against the issue’s reproduction steps.

Set up the application environment, authentication, and test data. Adapt locators where needed and add assertions for the expected result. For this sample, assert that the moved card is in In progress and no longer shows a Blocked badge. The supplied script only performs actions; see the [sample test adaptation](https://fairleadhq.com/docs/recorder/developers/playwright-export/#adapt-the-sample-recording).

Run the test against the affected behavior and then the fix. Keep the assertion that distinguishes the two. Share the fix or build reference and the expected result with QA for verification.

## Investigate with a coding agent

Give the agent the issue description, relevant artifacts, and application code with a focused task. For example: “Trace the sticky Blocked tag through the supplied HAR and notes, inspect the lane-change handler, and propose a regression test for clearing the badge when the card leaves Blocked.”

Ask it to cite the request, log entry, or action behind each finding and distinguish observations from hypotheses. Review the proposed change and test against the same evidence.

## Related investigation guides

- [Trace an action to a failure](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/) and [inspect GraphQL and streaming traffic](https://fairleadhq.com/docs/recorder/developers/graphql-and-streams/).
- [Reproduce a request](https://fairleadhq.com/docs/recorder/developers/reproduce-a-request/).
- [Build a reliable automated test](https://fairleadhq.com/docs/recorder/developers/reliable-automated-tests/).
- [Prepare evidence for coding agents](https://fairleadhq.com/docs/recorder/developers/agent-handoff/).

The export guides start from the generated file already present in the handoff: [Playwright](https://fairleadhq.com/docs/recorder/developers/playwright-export/), [Puppeteer](https://fairleadhq.com/docs/recorder/developers/puppeteer-export/), and [Chrome DevTools Recorder](https://fairleadhq.com/docs/recorder/developers/devtools-export/).

## Inspect and share evidence

Start with [Inspect a shared artifact bundle](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/). Use the focused guides for [recorded actions](https://fairleadhq.com/docs/recorder/developers/action-evidence/), [network requests](https://fairleadhq.com/docs/recorder/developers/network-evidence/), [console evidence](https://fairleadhq.com/docs/recorder/developers/console-evidence/), [screenshots](https://fairleadhq.com/docs/recorder/developers/image-evidence/), or [environment and timing](https://fairleadhq.com/docs/recorder/developers/performance-evidence/) when that source becomes decisive.

Before handing evidence to another person or tool, [review the supplied files for sensitive data](https://fairleadhq.com/docs/recorder/developers/review-evidence/). Refer to [report structure and artifact formats](https://fairleadhq.com/docs/recorder/schema/) for field meanings and file relationships, and [capture support and limits](https://fairleadhq.com/docs/recorder/developers/capture-support/) when evidence is missing or incomplete.

For agents reading these guides, use the [Markdown version](https://fairleadhq.com/docs/recorder/developers.md), [documentation index](https://fairleadhq.com/llms.txt), or [full documentation corpus](https://fairleadhq.com/llms-full.txt).

---

# Read recorded actions from artifacts
Canonical: https://fairleadhq.com/docs/recorder/developers/action-evidence/
Markdown: https://fairleadhq.com/docs/recorder/developers/action-evidence.md

Reconstruct the retained interaction from session and generated action files.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Read session.md, steps.json, and generated scripts without relying on Recorder Viewer controls.

## Prerequisites

- A bundle containing session.md and at least one action export

## Inputs

- Numbered actions, DevTools steps, or generated scripts

## Outputs

- A bounded action sequence with identified gaps

## Limitations

- Artifact files do not reproduce the Viewer event log, filters, or inferred links

## Permissions

- Access to the supplied files

## Privacy

- Review recorded URLs and input values before sharing or replaying action exports

Use `session.md` to understand what the tester did, then use `steps.json` or a generated script when you need selectors and runnable actions. Treat these files as a retained sequence, not as a complete record of every interaction or review decision.

## Reconstruct the retained sequence

Read the session start, duration, starting page, and numbered **Recorded actions** in `session.md`. Action offsets are relative to the recorded session start. Earlier interactions may be missing because Recorder retains a bounded timeline.

Compare the sequence with the tester's written steps. Repeated input and change events can describe one logical interaction. Navigation, keyboard input, file selection, frame boundaries, and complex widgets can be incomplete or represented differently across exports.

## Compare the action formats

`steps.json` is a Chrome DevTools Recorder flow. Its array indexes and setup steps do not match the numbered actions in `session.md`. It can include an initial viewport and navigation step that were generated to give the flow a starting point.

`playwright.spec.ts` and `puppeteer.js` are conversions of supported actions. Inspect their locators, values, and comments for omitted or redacted steps. They do not include assertions for the tester's expected result unless someone added them after generation.

Join formats by the action's label, target, value, and order rather than by array index alone. Treat positional selectors and long generated CSS selectors as candidates that must be checked against the application.

## Connect an action to other evidence

Use the relative offset in `session.md` and the absolute request time in `network.har` to find nearby traffic. Confirm the same subject with an identifier, payload value, route, or returned record. A nearby request may be polling or unrelated background work.

Use `notes.md` when it names an action or target. Compare screenshots with the sequence, but do not infer an image's exact timing unless the summary or note supplies it.

## Record the gaps

State which setup occurred before the retained interval, which actions are absent or ambiguous, and which values were redacted. Ask the tester for a focused new recording when the missing interaction changes the conclusion. Use [Capture support and limits](https://fairleadhq.com/docs/recorder/developers/capture-support/) to explain the boundary without implying that the bundle can be reopened in Recorder.

---

# Prepare evidence for coding agents
Canonical: https://fairleadhq.com/docs/recorder/developers/agent-handoff/
Markdown: https://fairleadhq.com/docs/recorder/developers/agent-handoff.md

Give an agent reviewed evidence and a concrete investigation task.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Give an agent reviewed evidence and a concrete investigation task. No native Recorder MCP or CLI; provide reviewed files and application context.

## Prerequisites

- An agent destination approved for the evidence

## Inputs

- Reviewed artifacts and a specific investigation task

## Outputs

- A bounded handoff with observations and known gaps

## Limitations

- No native Recorder MCP or CLI; provide reviewed files and application context

## Permissions

- Authorization to share the selected evidence with the agent destination

## Privacy

- Review logs and recorded values before copying or running artifacts

Give a coding agent the expected behavior, observed result, and relevant files so it can investigate the same check you performed.

## Select the evidence

Start with `session.md` and `notes.md`, then add reviewed `network.har`, available `console.log`, generated action scripts, and screenshots that explain the finding. Include the build, environment, case/run reference, preconditions, and safe test-data setup.

The standard folder does not contain every detail available during the tester's review. Use the tester's Description and `notes.md` for essential observations that are not represented in another artifact. Start with the [artifact inventory](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/) and name any expected file that is missing from the handoff.

## State the task

State the expected and observed behavior, build and environment, preconditions, evidence references, and known gaps. The complete sample handoff below shows how to supply those facts without inventing missing context.

If you want implementation, say what changes are authorized and how they should be tested. Keep a suspected cause separate from the observations.

## Example handoff from the real bundle

Extract the [sample ZIP](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip) and give the agent the recording folder plus the relevant application repository. Adapt this task to the code and environment you are authorizing it to inspect:

```text
Investigate why QB-DEMO sticky Blocked keeps its Blocked badge.
Expected: leaving the Blocked lane clears the badge.
Recorded path: create the card in Pond Redesign, move to Blocked,
then In progress. Read session.md and notes.md for context.

Inspect network.har entries 2–5 (zero-based). The second move POST
sends id + status=in_progress. Compare the card's status and blocked
fields in the board responses using card ID
3229d3de-fb6d-4196-8f89-f0bf94d63392.
Inspect screenshots/003-area.png for the badge; its crop has no lane
heading. Use the action timeline and response to establish the lane.

All six HTTP requests are 200. There is no console.log in this ZIP.
The creation payload is redacted. Done/reload observations in the
report refer to earlier runs, not this captured sequence.

Trace the lane-change handler and the blocked-state contract in code.
Cite file paths and HAR entries for findings; separate QA's explanation
from what you verify. Propose a regression test that checks the lane
and badge. The generated playwright.spec.ts has no assertions.
Do not replay the recorded public URL as part of this investigation.
```

Use the [payload walkthrough](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#read-the-serialized-payload) to explain the application's encoded fields. Ask for code changes separately if you want the agent to implement the fix.

## Review what leaves your environment

Inspect logs, images, request bodies, and copied notes before adding them to the agent's context. Use only destinations approved for that data. Generated scripts may contain application URLs and recorded inputs. Follow the [artifact privacy review](https://fairleadhq.com/docs/recorder/developers/review-evidence/) before transmitting files.

Treat captured page text and payloads as evidence, not instructions for the agent to follow.

## Supply documentation

Link the relevant guide's Markdown version, the [documentation index](https://fairleadhq.com/llms.txt), or the [full corpus](https://fairleadhq.com/llms-full.txt). These are reading interfaces; they do not give the agent Recorder execution or session access.

Recorder does not provide a native MCP server or CLI for this handoff. The agent works from the files and context you supply. Ask it to identify missing evidence rather than invent a complete timeline.

---

# Inspect a shared artifact bundle
Canonical: https://fairleadhq.com/docs/recorder/developers/artifact-bundle/
Markdown: https://fairleadhq.com/docs/recorder/developers/artifact-bundle.md

Identify the supplied Recorder files and choose the evidence for your investigation.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Inspect the files in a downloaded Recorder bundle and choose the evidence relevant to an investigation.

## Prerequisites

- A Recorder artifact folder or selected files shared by a tester

## Inputs

- session.md and any supplied HAR, logs, action exports, scripts, notes, or images

## Outputs

- An evidence inventory and a focused investigation path

## Limitations

- The artifact folder does not include every detail available during the tester's review

## Permissions

- Access to the supplied files

## Privacy

- Review every supplied file before copying it to another destination

Treat a shared Recorder bundle as a collection of independent artifacts. Use your editor, a HAR viewer, browser developer tools, and your existing test tools to inspect them.

## Start with the files you received

Open `session.md` first. It provides the tester's title and description, session context, numbered actions, evidence counts, and links to files Recorder expected to generate. Then compare that list with the files that are actually present.

| Artifact | Use it for | Important boundary |
| --- | --- | --- |
| `session.md` | Expected and observed behavior, action order, start time, duration, and evidence counts | It contains tester-authored conclusions as well as generated summaries. |
| `notes.md` | Source-linked observations and field paths | It is omitted when the recording has no saved notes or pins. |
| `network.har` | Captured HTTP requests, responses, headers, bodies, and HAR timings | Bodies can be redacted, truncated, unavailable, or binary. |
| `console.log` | Captured console text and stack traces | It may be absent even when `session.md` contains a link to it. |
| `steps.json` | Chrome DevTools Recorder actions | It is not a Fairlead Report and does not contain every captured event. |
| `playwright.spec.ts` | Generated Playwright actions | It needs setup, safe data, stable locators, and assertions. |
| `puppeteer.js` | Generated Puppeteer actions | Reaching the final line does not establish a passing result. |
| `screenshots/*.png` | Visible state selected by the tester | Pixels are not automatically masked, and an image may omit decisive context. |

The folder is not a serialized runtime Report and is not a portable copy of the session Viewer. Viewer-only filters, privacy decisions, WebSocket frames, environment panels, and performance panels cannot be recovered from these files unless the tester separately described or exported the relevant observation.

## Choose the first artifact

- Start with `session.md` and `notes.md` to understand the claim and locate the decisive action.
- Open `network.har` when the question concerns submitted data, returned state, timing, or an application-level error.
- Open `console.log` when the browser reported an exception or diagnostic message.
- Compare screenshots with the action and response when the visible state is decisive.
- Use the generated action files only when you are authorized to reproduce the flow in a controlled environment.

Keep observations from each file separate until identifiers, values, and timestamps support joining them. Proximity in time suggests where to investigate; it does not prove causation.

## Handle missing or partial bundles

Do not infer that an absent file was empty. Ask the sender whether the file was not generated, failed to download, was intentionally withheld, or contained no supported entries. State which conclusion is blocked by the gap.

If evidence that is not represented in the supplied files is necessary, ask the tester to record the observation in Description or a source-linked note and download a new bundle. Name the missing observation instead of asking for “the whole session.”

Use the [sample bundle](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) to practise the file-first workflow. It contains no runtime Report or `console.log`, and its screenshots need the action timeline and HAR to establish the final lane.

---

# Capture support and limits
Canonical: https://fairleadhq.com/docs/recorder/developers/capture-support/
Markdown: https://fairleadhq.com/docs/recorder/developers/capture-support.md

Check timeline, session-budget, event, frame, and export boundaries.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — e6261af

Agent summary: Check retained-timeline, session-budget, and artifact boundaries before interpreting a shared bundle.

## Prerequisites

- A planned recording or artifact to evaluate

## Inputs

- Required evidence and capture conditions

## Outputs

- Known support and format boundaries

## Limitations

- The retained timeline and session payload are bounded; downloaded artifacts omit Viewer-only evidence and cannot be imported into Recorder

## Permissions

- None declared.

## Privacy

- Review logs and recorded values before copying or running artifacts

Use these boundaries when deciding what a shared bundle can establish and what needs another tool or a separate execution summary.

<span id="retention-and-browser-scope"></span>
<span id="recording-retention"></span>

## Timeline and session limits

Recorder does not stop after a fixed number of recorded actions. Capture begins only after **Start recording**, and at **Stop** Recorder retains up to the last **120 seconds** of timeline events. If the recording is shorter than this limit, the retained interval begins at Start; otherwise, older events are discarded as the recording continues.

The elapsed duration in `session.md` measures the whole recording, not how much evidence remains. If the attempt exceeded the retained timeline, treat early setup as unrecorded unless another supplied artifact establishes it. Ask the tester for separate checkpoint bundles when the missing interval matters.

This timeline limit is the same for local and connected recordings. Signing in or navigating does not extend it. There is no pre-Start action replay, and screenshots or written observations cannot recover discarded events. Metadata, notes, attachments, and downloaded or uploaded copies have separate lifetimes; this window is not a deletion schedule for all session data.

Separate per-session budgets protect storage and processing. The current defaults allow a report of up to 16 MiB, up to 5,000 HTTP requests including 3,000 non-static requests, and up to 10 attachments. Each attachment can be up to 2 MiB, with 20 MiB available across attachments. The Data Plane enforces these limits for uploads and processing; local review and export can remain available when an upload is rejected. These are payload and request limits, not a recorded-action limit.

## Browser scope

Recorder capture is supported in Google Chrome on a computer. Browser-internal and extension pages are restricted; account-free mode also excludes local file URLs. Broad host permission does not bypass the local hostname scope or connected project rules. Use these facts to interpret a gap in the bundle, not as steps for opening the bundle in Recorder.

## Actions, frames, and components

Supported action evidence includes clicks, input/control changes, selected keyboard actions, scrolling, and navigation. `session.md` contains a numbered action summary, while `steps.json` and generated scripts contain their own converted action forms. These files do not reproduce the complete event log or action detail panels.

Iframe provenance and open-shadow-root targets can be recorded. Untrusted iframe values, closed shadow roots, unavailable target information, and complex widgets can limit capture or generated locators. Keyboard evidence is not a complete focus history.

## Bodies and size limits

Payload limits depend on configuration; the account-free default is 512 KiB. Bodies can be truncated, unavailable, filtered, or represented by binary placeholders. Browser protocol availability and streaming behavior affect completeness.

Screenshot attachments also face destination-specific size limits. A tracker rejecting an image does not necessarily mean issue creation failed.

## Performance evidence

Available observations include FCP, LCP, long tasks, and selected resource timing. Observer support varies. Buffered paint/resource measurements can predate Start; long tasks are observed during capture with a 50 ms threshold. INP and CLS are not calculated.

## Bundle versus runtime evidence

The runtime Report, HAR, DevTools JSON, and generated scripts are distinct formats. A standard bundle is not a serialized runtime Report. WebSocket frames, environment panels, performance panels, filters, source navigation, and privacy decisions are not reconstructed from the download. Screenshots are added explicitly and are not automatically masked.

Use [Inspect a shared artifact bundle](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/) for the portable file set and its omission rules.

See [artifact formats](https://fairleadhq.com/docs/recorder/schema/) before building tooling or asserting complete coverage. If a necessary observation exists only in Recorder, ask the tester to write it into Description or a source-linked note and provide a new reviewed bundle.

---

# Inspect console evidence from a bundle
Canonical: https://fairleadhq.com/docs/recorder/developers/console-evidence/
Markdown: https://fairleadhq.com/docs/recorder/developers/console-evidence.md

Read captured console text and relate it to the reported behavior.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Inspect console.log as supplied text. An absent or clean log does not establish a passed test.

## Prerequisites

- A bundle that may contain console.log

## Inputs

- Console messages, stack traces, and the tester's expected and observed result

## Outputs

- Relevant console observations with source and timing limits

## Limitations

- The text export does not reproduce Viewer filters, detail panels, or inferred action links

## Permissions

- Access to the supplied evidence

## Privacy

- Console text is not universally sanitized and needs manual review

Open `console.log` as text in your editor. Use search, timestamps, stack frames, and the surrounding artifacts to identify relevant messages.

## Find relevant messages

Search for an exception name, application module, endpoint, subject identifier, or time near the reported action. Read the full message and available stack together. Distinguish application messages from browser, extension, or third-party output before following a stack into code you own.

Compare the message time with `session.md` and `network.har`. A message close to an action or request is a lead, not proof that the action caused it. Check whether the stack, request result, and visible state support the same explanation.

## Interpret missing evidence

Check whether `console.log` is actually present. `session.md` can link to an expected filename even when the downloader omitted it. An absent file can mean there were no exported entries, a download was partial, or the file was not supplied.

A zero console-error count does not establish that the acceptance criteria passed. The sample bundle has a visible state defect and six successful HTTP responses but no `console.log`.

If the missing console context matters, ask the tester for the exact message, stack, source, and time in a new description or note. Do not ask them to send “the Viewer”; a bundle cannot reproduce it.

## Share the useful portion

Include the smallest relevant excerpt with the expected result, observed result, source, timestamp, and related request or action. Review the text for credentials, tokens, personal data, application payloads, and internal URLs before copying it to an issue or another tool.

---

# Replay a Chrome DevTools Recorder flow
Canonical: https://fairleadhq.com/docs/recorder/developers/devtools-export/
Markdown: https://fairleadhq.com/docs/recorder/developers/devtools-export.md

Import recorded actions as a JSON user flow.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Import recorded actions as a JSON user flow. Initial navigation does not restore login or data; unsupported actions need adaptation.

## Prerequisites

- A supplied steps.json file; Chrome DevTools available

## Inputs

- Reviewed steps.json and application preconditions

## Outputs

- An imported flow checked against the intended behavior

## Limitations

- Initial navigation does not restore login or data; unsupported actions need adaptation

## Permissions

- Authorization to replay against the target environment

## Privacy

- Review logs and recorded values before copying or running artifacts

Use `steps.json` to bring supported recorded actions into Chrome DevTools Recorder. Prepare the target application state before replaying the flow.

## Locate the supplied actions

Find `steps.json` in the [shared artifact bundle](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/). Open it in Chrome DevTools Recorder to inspect and replay the captured flow.

The file describes a DevTools user flow. It is not the complete Fairlead session Report or the entire sample reproduction archive.

## Review the preconditions

Inspect the starting URL and recorded values. If capture began on an already loaded page, Recorder adds an initial navigation so the exported flow has a starting page.

That navigation does not restore authentication, existing data, or earlier actions. Supply those preconditions separately. Redacted inputs become literal `[redacted]` values in the flow. Replace them with safe test data before replay.

Selector alternatives include available CSS candidates and XPath fallbacks. All exported action targets use `main`; iframe actions need frame targeting added before replay. Keyboard actions are omitted. File controls are not exported as file-upload steps; replace any generic change with the required upload action. Review ambiguous or dynamic selectors as well.

## Import and replay

1. Open Chrome DevTools and its **Recorder** panel.
2. Select **Import** and choose `steps.json`.
3. Review the imported steps.
4. Select **Replay** when the target environment and data are ready.

Chrome accepts JSON user flows through this import path. See the [DevTools Recorder reference](https://developer.chrome.com/docs/devtools/recorder/reference#import) for its flow controls.

## Inspect the sample flow

The [sample ZIP](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip) contains a `steps.json` with 22 steps. It starts with `setViewport` (1920 × 907, device scale factor 2) and `navigate`, followed by the card-creation and lane-change interactions. The 21 numbered actions in `session.md` use a different numbering scheme; do not join the two files by array index.

Importing the flow lets you inspect it before replay. Review the recorded public URL, signed-in project state, repeated input changes, and positional selectors. The initial navigation's `assertedEvents` checks navigation, not whether the card's Blocked badge clears. Add the expected lane and badge checks in your test workflow; see [adapting the sample test](https://fairleadhq.com/docs/recorder/developers/playwright-export/#adapt-the-sample-recording).

## Check the result

Compare the replay with the intended test, not only with the absence of errors. Unsupported actions and missing retained history may require manual steps or edits. Add the checks needed to assess expected behavior.

If DevTools import or replay fails, verify the file type, starting state, selectors, and redacted inputs. Ask the sender whether the download was partial when `steps.json` is missing or invalid.

---

# GraphQL and streaming traffic
Canonical: https://fairleadhq.com/docs/recorder/developers/graphql-and-streams/
Markdown: https://fairleadhq.com/docs/recorder/developers/graphql-and-streams.md

Inspect application errors and streaming evidence beyond HTTP status.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Inspect application errors and streaming evidence beyond HTTP status. HTTP 200 can contain GraphQL errors; standard downloads omit WebSocket frames.

## Prerequisites

- A shared network.har and any separately recorded stream observations

## Inputs

- GraphQL or EventStream or WebSocket evidence

## Outputs

- Message-level observations with transport context

## Limitations

- HTTP 200 can contain GraphQL errors; standard downloads omit WebSocket frames

## Permissions

- Access to the recorded evidence

## Privacy

- Review logs and recorded values before copying or running artifacts

Inspect GraphQL evidence in `network.har` and treat streaming details as a separate handoff requirement. A successful transport response can still carry an application error.

## Inspect GraphQL

Open `network.har` in a HAR viewer or editor. Find the operation by URL, `postData`, operation name, variables, time, or subject identifier, then inspect its request and response content.

An HTTP 200 response can contain GraphQL errors. Read the error details and returned data together; partial data can matter to the visible result. Add the operation and relevant fields to the issue without assuming the HTTP status alone determines success.

## Evaluate EventStream evidence

The standard bundle does not guarantee a portable copy of Recorder's EventStream message view. Inspect any HTTP headers and content present in `network.har`, plus stream observations the tester wrote into `session.md` or `notes.md`. A long-lived connection may not have a conventional completed response body.

Capture duration and payload limits still apply. Missing messages can reflect retention or capture availability rather than a server that sent nothing.

## Evaluate WebSocket evidence

WebSocket frames are not included in the standard bundle. A HAR entry can establish connection context without preserving the message sequence. Use separately supplied notes or a dedicated protocol capture when frame content is decisive. Distinguish connection establishment from message-level behavior.

Do not assume a WebSocket frame can be reproduced as an ordinary HTTP request.

## Choose the handoff format

`network.har` carries HTTP request/response evidence. WebSocket frames are not included in the standard bundle, and EventStream Viewer details do not have a guaranteed full-fidelity equivalent in another HAR viewer.

Ask the tester to record important stream observations and timestamps in Description or a source-linked note before producing a new bundle. Review message content for sensitive values before copying it.

Use [capture support](https://fairleadhq.com/docs/recorder/developers/capture-support/) for retention and size boundaries.

---

# Inspect screenshots from a bundle
Canonical: https://fairleadhq.com/docs/recorder/developers/image-evidence/
Markdown: https://fairleadhq.com/docs/recorder/developers/image-evidence.md

Use supplied images as visible-state evidence without assuming missing context.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Inspect screenshot files alongside the action timeline and network evidence. Screenshot pixels are not automatically masked.

## Prerequisites

- A bundle containing screenshot or image files

## Inputs

- Supplied images, session.md, and any image notes

## Outputs

- A visible-state observation with explicit context and privacy limits

## Limitations

- An image does not by itself establish its timing, page state, or relation to a request

## Permissions

- Access to the supplied images

## Privacy

- Inspect every pixel before sharing; Recorder does not provide pixel masking in the bundle

Open the files under `screenshots/` with your normal image viewer. Use their filenames, timestamps, and the surrounding artifacts to establish where each image belongs in the investigation.

## Establish what the image shows

Read the corresponding entry in `session.md` or `notes.md` when one exists. Record the filename, visible subject, expected state, observed state, and any context outside the crop.

The `full` filename suffix means a visible viewport capture, not a stitched full-page image. An area capture can omit a lane heading, account identity, error message, or other relationship needed for the conclusion. Use the action sequence or returned data to supply only context that those artifacts actually establish.

An externally added image can describe a useful state without proving when that state occurred. Treat timing or provenance written by the tester as an authored observation unless another artifact supports it.

## Compare with the same subject

Use stable text, a record ID, filename note, or surrounding action to connect the image to `network.har` and `session.md`. Do not join evidence only because it appears near the same time.

In the sample bundle, `003-area.png` shows the Blocked badge but omits the lane heading. The recorded In progress action and final board response establish the lane; the pixels establish the remaining badge.

## Review and share safely

Inspect names, messages, account details, tokens, QR codes, browser chrome, and background content. Screenshot pixels are not automatically masked. If an image is unsafe, request a retaken or separately edited copy using safe data; preserve the original only in an approved location.

Share only the images needed for the conclusion and state what each one cannot show. An omitted file is different from a sanitized connected report, and excluding a file from your handoff does not alter copies already shared.

---

# Inspect network evidence from a HAR
Canonical: https://fairleadhq.com/docs/recorder/developers/network-evidence/
Markdown: https://fairleadhq.com/docs/recorder/developers/network-evidence.md

Find and interpret captured requests without the Recorder Viewer.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Inspect network.har with a HAR viewer or editor. HTTP status alone does not establish application success.

## Prerequisites

- A supplied network.har file

## Inputs

- Captured HTTP requests, responses, headers, bodies, and timings

## Outputs

- Relevant request observations and explicit evidence gaps

## Limitations

- The standard HAR omits Viewer-only streaming evidence and can contain redacted or truncated bodies

## Permissions

- Access to the HAR and authorization for any request replay

## Privacy

- Review URLs, headers, cookies, and bodies before copying or replaying them

Open `network.har` in a trusted HAR viewer or inspect its JSON in your editor. Search and filter it with the tool you already use.

## Find the relevant entry

Start with the failing action in `session.md`. Convert its relative offset to an approximate absolute time using the session start, then search `log.entries` by `startedDateTime`, method, URL, subject identifier, or payload value.

Confirm the candidate with more than timing. Match the same record ID, operation name, request body, or returned object. Background requests and polling can occur near the same action.

## Inspect the request and response

For the selected entry, compare:

- `request.method`, `request.url`, query parameters, headers, cookies, and `postData`;
- `response.status`, headers, cookies, and `content`;
- HAR timing fields and the request's absolute start time;
- redaction markers, missing text, truncation, and binary placeholders.

An HTTP 200 can still contain an application error or returned state that violates the expected behavior. For GraphQL, inspect the operation payload, returned `errors`, and partial `data` together.

HAR timing is browser-observed request timing, not the tester's complete wait or a server profiler. Compare it with the visible result described in `session.md`, `notes.md`, and screenshots.

## Understand what is absent

The standard bundle's HAR represents captured HTTP traffic. It does not preserve the Recorder network Viewer's filters, source links, WebSocket frame list, or every EventStream detail. A missing body or stream message is an evidence gap, not proof that the server sent nothing.

If stream content is decisive, ask the tester to preserve the observation in Description or `notes.md`, or collect it with an appropriate browser or protocol tool in a new authorized attempt.

Use [Reproduce a request](https://fairleadhq.com/docs/recorder/developers/reproduce-a-request/) only after a read-only inspection and only when replay will answer a specific remaining question.

---

# Read environment and timing artifacts
Canonical: https://fairleadhq.com/docs/recorder/developers/performance-evidence/
Markdown: https://fairleadhq.com/docs/recorder/developers/performance-evidence.md

Separate portable bundle evidence from Viewer-only performance observations.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Use session.md and HAR timing for portable context. Standard bundles do not export every environment or performance panel.

## Prerequisites

- A shared bundle and the reported timing or environment condition

## Inputs

- Session context, HAR timings, and tester-authored measurements

## Outputs

- A bounded timing observation and the next diagnostic step

## Limitations

- Standard bundles do not contain every Viewer environment, lifecycle, or performance record

## Permissions

- Access to the supplied evidence and authorization for any new profiling

## Privacy

- Review URLs, device context, and captured values before sharing

Use the portable context in `session.md` and `network.har` first. The standard artifact folder does not include the Environment, Timeline, or performance-panel data.

## Identify available context

`session.md` can supply the start time, duration, starting page, and browser user agent. It does not necessarily include the application build, account role, test-data state, connection conditions, colour scheme, viewport, or every browser measurement. Take those facts from the tester's Description or notes only when they were explicitly recorded.

`network.har` supplies request start times and HAR timing phases for captured HTTP traffic. Use those values to identify a long request or a request interval, not as a complete measurement of when the page became usable.

## Separate the measurements

Keep these claims distinct:

- HAR timing describes a captured request as observed by the browser.
- A tester-authored wait describes elapsed user experience and should name the measurement method.
- A screenshot establishes a visible state at an authored or correlated point.
- FCP, LCP, long-task, lifecycle, and resource observations can exist while Recorder assembles the report, but the standard bundle does not provide them as a portable performance artifact.

Recorder does not calculate Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), or a complete responsiveness verdict. Do not infer a missing metric as zero.

## Decide the next step

If the HAR shows one long request, investigate that route and its server timing. If the response completed before the UI became ready, inspect client work with browser performance tooling. If the bundle lacks the decisive interval, ask for a controlled new attempt with the wait and conditions written into the handoff.

Use a profiler or repeatable benchmark for root-cause or release-level performance decisions. The bundle helps identify where to measure next; it does not replace that measurement.

---

# Adapt a Playwright test
Canonical: https://fairleadhq.com/docs/recorder/developers/playwright-export/
Markdown: https://fairleadhq.com/docs/recorder/developers/playwright-export.md

Inspect a generated test and adapt it to your Playwright project.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Adapt a supplied Playwright file in your test project. Generated actions need assertions, fixtures, and safe test data.

## Prerequisites

- A supplied playwright.spec.ts file; a configured Playwright Test project

## Inputs

- Generated playwright.spec.ts and expected behavior

## Outputs

- An adapted test run from a clean state

## Limitations

- Generated actions need assertions, fixtures, and application-specific setup

## Permissions

- Authorization to run tests against the target environment

## Privacy

- Review logs and recorded values before copying or running artifacts

Start with the supplied `playwright.spec.ts`, then add the checks and setup your test needs.

## Inspect the script

Open `playwright.spec.ts` from the [shared artifact bundle](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/). Compare it with the expected behavior in `session.md`, the numbered action sequence, and any limitations recorded by the tester. Review the generated file directly for locator risks, redacted values, omitted actions, and comments.

## Prepare your test project

Use a project with Playwright Test and its browser dependencies installed. Follow the [Playwright installation guide](https://playwright.dev/docs/intro) if you need a test project first.

Place a reviewed copy in the project's test directory. Review the starting URL, authentication, input values, and data dependencies. The generated navigation does not recreate an already signed-in browser state.

Add fixtures or setup and cleanup for your application. Replace redacted values with approved test data. Review selectors and unsupported actions against the actual flow.

Keyboard actions and file-upload changes are omitted. Redacted inputs are skipped with comments, so add those steps using safe test data. Generated actions target the page; add frame locators for actions recorded inside iframes.

## Add an expected result

Add assertions for the behavior you intended to check. Generated actions alone do not establish a pass. Use [reliable automated tests](https://fairleadhq.com/docs/recorder/developers/reliable-automated-tests/) for locator, wait, and repeatability guidance.

## Adapt the sample recording

The [sample ZIP](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip) includes a real `playwright.spec.ts` for the sticky Blocked tag. It imports `test` but no assertion helper, sets a 1920 × 907 viewport, opens the recorded public URL, creates a card, and performs the two lane changes. Completing those actions would not detect the reported bug.

Before running a copy in your test project:

1. Replace the recorded URL with your authorized test environment and provide a signed-in state for Pond Redesign or equivalent test data.
2. Create a uniquely named disposable card and arrange cleanup. The exported title `QB-DEMO sticky Blocked` can collide with earlier runs.
3. Replace positional `nth-of-type` locators and long style-class selectors with stable application locators. Scope the card by its unique identity across lane changes.
4. Review duplicate fills for `#qb-title` and `#qb-points`, plus the two clicks and `check()` on `#qb-top`. Preserve the intended final state when simplifying recorded events.
5. After moving into Blocked, assert that the card is in that lane and has the badge. After moving to In progress, assert both the new lane and absence of that card's Blocked badge.

Wait for the destination card to appear before checking the badge is absent, so a missing card cannot produce a false pass. If persistence is part of the agreed behavior, reload and repeat the checks as an additional test; the supplied recording does not include a reload.

The [HAR walkthrough](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#worked-example-the-sticky-blocked-tag) gives the request and returned state to compare with your test. A successful HTTP response alone is not the regression assertion.

## Run the adapted test

From a configured project, run the file using Playwright Test:

```sh
npx playwright test tests/playwright.spec.ts
```

Adjust the path to where you saved it. See Playwright's [command-line reference](https://playwright.dev/docs/test-cli).

Read any failure before changing timeouts. Confirm the locator, page state, response, and expected assertion. Repeat from a clean state before adding the test to your suite. Recorder exports the retained segment only; earlier evicted actions must be supplied as setup where required.

---

# Adapt a Puppeteer script
Canonical: https://fairleadhq.com/docs/recorder/developers/puppeteer-export/
Markdown: https://fairleadhq.com/docs/recorder/developers/puppeteer-export.md

Adapt recorded actions into a runnable Puppeteer workflow.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Adapt recorded actions into a runnable Puppeteer workflow. ES-module setup is required; generated actions are not complete test coverage.

## Prerequisites

- A supplied puppeteer.js file; a compatible Node.js and Puppeteer project

## Inputs

- Generated puppeteer.js and application setup

## Outputs

- An adapted script with checks and repeatability review

## Limitations

- ES-module setup is required; generated actions are not complete test coverage

## Permissions

- Authorization to run scripts against the target environment

## Privacy

- Review logs and recorded values before copying or running artifacts

Start with the supplied `puppeteer.js` and review it in your own test project before execution.

## Inspect the supplied script

Open `puppeteer.js` from the [shared artifact bundle](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/). Compare it with `session.md` and the expected result. Review the generated file directly for locator risks, redacted values, omitted actions, and comments. It uses Puppeteer directly rather than requiring a DevTools JSON replay runner.

## Prepare the runtime

The generated script uses ECMAScript imports and Puppeteer's locator API; its generated header specifies Puppeteer 25 or later. Use a Node.js environment compatible with the chosen Puppeteer release and configure the project for ES modules, or save a reviewed copy with an `.mjs` extension.

Install and configure Puppeteer following its [getting-started guide](https://pptr.dev/guides/getting-started). Keep dependency setup in your test project.

## Review the conversion

Supported navigation, clicks, fills, control changes, and other converted actions become script statements. Compare the script with the original check to find unsupported actions and incomplete targets.

Review selectors, especially repeated labels, dynamic identifiers, frames, and Shadow DOM. Supply authentication and data setup; initial navigation cannot restore pre-recording state. Replace masked values with safe test inputs.

Keyboard actions and file-upload changes are omitted. Redacted inputs are skipped with comments, so add those steps using safe test data. Generated actions target the page; add frame locators for actions recorded inside iframes.

## Inspect the real sample script

The [sample ZIP](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip) includes `puppeteer.js` for card creation and the Blocked → In progress moves. It uses recorded values and selectors, opens the recorded public URL, and contains no badge assertion. Change the destination and supply your test environment's login and disposable data before execution. Review repeated input events and positional locators against the application.

Add checks that the card is present in In progress and its Blocked badge is absent. A successful sequence of clicks alone misses the defect. The sample's creation request is redacted, so the HAR does not provide complete fixture setup.

## Add checks and run

Add assertions for the intended behavior and appropriate waits and cleanup. Follow [reliable automated tests](https://fairleadhq.com/docs/recorder/developers/reliable-automated-tests/) before treating the script as regression coverage.

In an ES-module project with dependencies available:

```sh
node puppeteer.js
```

Run against an appropriate test environment and inspect the outcome. A script reaching its last line does not prove your acceptance criteria were checked. Repeat from a clean state and investigate locator or precondition failures before changing timing.

---

# Turn a recording into a reliable automated test
Canonical: https://fairleadhq.com/docs/recorder/developers/reliable-automated-tests/
Markdown: https://fairleadhq.com/docs/recorder/developers/reliable-automated-tests.md

Add checks and repeatable setup to generated browser actions.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Add checks and repeatable setup to generated browser actions. Generated actions alone do not establish correct behavior; unsupported actions need adaptation.

## Prerequisites

- A generated flow and a configured test project

## Inputs

- Expected results and recorded actions

## Outputs

- A repeatable test with assertions and setup and cleanup

## Limitations

- Generated actions alone do not establish correct behavior; unsupported actions need adaptation

## Permissions

- Authorization to run tests against the chosen environment

## Privacy

- Review logs and recorded values before copying or running artifacts

Use generated actions as the starting point for a test. A useful automated test also needs an expected result, stable setup, and a clear failure signal.

## Define the assertion

Write what the test must prove before editing the script. For the supplied card-board recording, check the destination lane and whether the Blocked badge clears.

An action completing without an exception does not establish that the feature works. Add assertions in your test project; Recorder does not provide an assertion editor.

## Define the sample's regression assertion

The [sample recording](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) moves a card into Blocked, then In progress, but the badge remains. A useful test must first find that card in the destination lane and then check the badge is absent. Otherwise an absent card can produce a false pass. Its generated scripts contain actions without these assertions. See [adapt the sample recording](https://fairleadhq.com/docs/recorder/developers/playwright-export/#adapt-the-sample-recording) for the concrete setup and locator review.

## Review locators

Replace ambiguous or unstable selectors with locators that identify the intended control reliably. Check repeated labels, dynamic identifiers, iframe boundaries, and component structure against the application.

Compare locators across the supplied script, `steps.json`, and the application's current markup, then verify them against the test environment. A generated selector is a candidate, not a stability guarantee.

## Make setup repeatable

Provide safe test data and the required authentication, permissions, and application state. A generated initial navigation opens the starting URL but does not recreate its prior state.

Keep secrets in the test project's approved configuration. Arrange cleanup for data created by the test and isolate it from other runs.

## Wait for observable conditions

Wait for the response or UI state the next action depends on, rather than adding arbitrary delays to match the original recording. Use your framework's supported locator and assertion mechanisms. Playwright's retrying assertions are one example; see its [assertion guide](https://playwright.dev/docs/test-assertions).

## Verify repeatability

Run the test from a clean starting state, then repeat it. Check that it fails when the expected behavior is deliberately unmet in a controlled test scenario. Investigate intermittent results rather than increasing every timeout.

Review unsupported or missing actions against the original test. Only the retained recording segment was exported.

## Choose an export

Follow [Playwright](https://fairleadhq.com/docs/recorder/developers/playwright-export/), [Puppeteer](https://fairleadhq.com/docs/recorder/developers/puppeteer-export/), or [Chrome DevTools Recorder](https://fairleadhq.com/docs/recorder/developers/devtools-export/). Recorder does not run the resulting suite or synchronize its results to a TMS.

---

# Reproduce a request from a HAR
Canonical: https://fairleadhq.com/docs/recorder/developers/reproduce-a-request/
Markdown: https://fairleadhq.com/docs/recorder/developers/reproduce-a-request.md

Use captured request evidence in a controlled reproduction.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Reconstruct a reviewed request from network.har in a controlled environment. Replay can modify data and does not reproduce browser state.

## Prerequisites

- A recorded request and an authorized test environment

## Inputs

- Reviewed request headers and body

## Outputs

- A controlled reproduction and response comparison

## Limitations

- Replay can modify data and does not reproduce browser state; missing or redacted request data cannot be recovered from the bundle

## Permissions

- Authorization to execute the request in the chosen environment

## Privacy

- Review logs and recorded values before copying or running artifacts

Reconstruct a request from the supplied `network.har` to investigate it outside the original browser interaction. Review the destination, credentials, and side effects before executing it.

## Extract the request

1. Open `network.har` in a trusted HAR viewer or editor.
2. Find the entry by method, URL, absolute time, subject identifier, or payload value.
3. Inspect its URL, headers, cookies, query values, and `postData` before constructing a command in your HTTP tool.
4. Remove or replace expired credentials and change the destination to an authorized test environment.

Some HAR tools can generate cURL, but inspect their output before execution. Preserve the captured body format rather than rewriting it into a more familiar shape.

## Inspect a request from the sample files

In the [sample investigation](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#worked-example-the-sticky-blocked-tag), `log.entries[4]` is the POST that moves the card to In progress. Its method, URL, headers, and serialized `postData.text` describe the captured request.

The body wraps `id` and `status` in an application-specific encoding. Replacing it with a plain `{ "id": "…", "status": "in_progress" }` object would change the wire format. Use the target application's client or the correct serialized body for its current build. The captured `/_serverFn/` route may also change between builds.

Start with the read-only comparison: the POST sends no `blocked` field and the subsequent GET retains the blocked value. Replay only if it will answer a remaining question, using your own test card and environment. The sample's creation body is redacted, so it cannot supply complete setup.

## Prepare a safe reproduction

Read the URL, method, headers, and body. Change the destination to an appropriate test environment if necessary. Supply approved test credentials for redacted or expired values. Check cookies and anti-forgery tokens rather than assuming they remain valid.

A replayed request can create, update, or delete data. Confirm the operation and use disposable test records where needed. Do not execute copied commands blindly.

## Compare the response

Run the reviewed request with your HTTP tooling and compare status, response content, and timing with the recorded evidence. Record which inputs or headers you changed.

A cURL request does not reproduce the browser's DOM state or browser-enforced cross-origin behavior. A success outside the browser may therefore narrow the investigation without resolving the original failure.

## Handle incomplete evidence

Missing or truncated bodies cannot be recovered by copying the request. Streaming messages and WebSocket frames are not equivalent to an ordinary request replay. If required context is absent, capture a new focused attempt with suitable rules.

Share the result, original evidence reference, and changed conditions with the investigator. Keep credentials out of the issue and shared command text.

---

# Review shared artifacts for sensitive data
Canonical: https://fairleadhq.com/docs/recorder/developers/review-evidence/
Markdown: https://fairleadhq.com/docs/recorder/developers/review-evidence.md

Inspect the files you received before copying, replaying, or forwarding them.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Review the supplied bundle files before sharing them with another person or system.

## Prerequisites

- A Recorder bundle or selected artifact files

## Inputs

- Text, structured traffic, scripts, logs, notes, and images

## Outputs

- A reviewed set of files for an approved destination

## Limitations

- Post-download review cannot change the original recording or retract earlier copies

## Permissions

- Permission to inspect and share the selected evidence

## Privacy

- Review every file and image; automatic redaction is not universal

Review the actual files you received before sending them to an issue tracker, coding agent, chat, repository, or another person. Make any necessary changes in a safe working copy and verify the final files themselves.

## Inventory the handoff

Compare the files present with `session.md`. A link in the summary does not guarantee the file exists, and a partial handoff may intentionally omit evidence. Review each supplied artifact:

| Artifact | Check for |
| --- | --- |
| `session.md`, `notes.md` | Names, URLs, account or project details, copied payloads, and tester-authored conclusions |
| `network.har` | Query values, headers, cookies, credentials, request bodies, response bodies, and internal endpoints |
| `console.log` | Tokens, personal data, application payloads, stack paths, and internal URLs |
| `steps.json`, generated scripts | Recorded URLs, input values, selectors, comments, and test data |
| `screenshots/` | Sensitive pixels anywhere in the image, including browser chrome and background content |

Automatic sanitization can cover selected structured values, but it does not certify the bundle as safe. Missing or truncated content is an evidence gap, not a privacy guarantee.

## Choose a safe response

If a file contains material you cannot share, omit it from the destination or prepare a separately reviewed copy with an appropriate file-aware tool. Preserve the original only in an approved location. For screenshots, retake or edit a copy outside Recorder; there is no pixel-redaction control in the bundle.

Avoid ad hoc edits that make structured files invalid. After changing a HAR or JSON copy, parse it with the intended consumer and verify that the evidence you meant to preserve is still present. Never replace a redacted credential with a real production secret for convenience.

When the required evidence cannot be made safe or remains incomplete, ask the tester for a new reviewed export using safe test data. Name the exact request, field, message, action, or image needed.

## Verify the destination

Send only the reviewed copies required for the task. Confirm that the destination received those files and no unintended siblings. Record exclusions that limit the conclusion.

Later edits cannot retract an earlier email, issue attachment, upload, or agent context. Treat each destination as an independent disclosure and follow its access and retention rules.

---

# The session identifier
Canonical: https://fairleadhq.com/docs/recorder/developers/session-identifier/
Markdown: https://fairleadhq.com/docs/recorder/developers/session-identifier.md

How one identifier joins a recorded session to the requests your own servers logged.

Updated: 2026-10-10
Publication state: published
Product version: platform

Agent summary: Connected Recorder sessions send reproduction and optional issue or request identifiers; backend logging must retain them. Capture domain rules do not restrict header injection.

## Prerequisites

- An application that logs request headers

## Inputs

- A recorded session

## Outputs

- A request header present in your own access log

## Limitations

- It appears only where your application or proxy logs that header

## Permissions

- None declared.

## Privacy

- Connected headers can reach third-party request destinations

Use Recorder’s reproduction and request identifiers to connect browser evidence with backend logs and traces. This requires a connected recording and application middleware or other instrumentation that logs the incoming headers.

## Recorder identifiers

The minimal set of identifiers produced by RECORDER:
- `x-fairlead-reproduction-id` identifies the recording attempt and is sent during connected capture.
- `x-fairlead-issue-id` identifies the selected issue when enabled and supplied.
- `x-fairlead-correlation-id` identifies an individual request when enabled.

Account-free recordings do not send these headers. Capture domain rules do not limit header injection; requests to third-party origins can receive the identifiers too.

Inspect the supplied `network.har` for request headers and use [Correlate with backend logs](https://fairleadhq.com/docs/recorder/session-correlation/) for verification. Locally recorded IDs alone do not establish that a server received them. If the required header is missing, ask the tester for the identifier or a newly reviewed artifact.

## Format boundaries

The runtime Report and downloadable artifacts are described in [Report structure and artifact formats](https://fairleadhq.com/docs/recorder/schema/). It does not establish a shared header contract for other Fairlead products.

---

# Trace an action to a failure
Canonical: https://fairleadhq.com/docs/recorder/developers/trace-a-failure/
Markdown: https://fairleadhq.com/docs/recorder/developers/trace-a-failure.md

Follow recorded actions, requests, and errors while keeping causality explicit.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Follow recorded actions, requests, and errors while keeping causality explicit. Action associations are timing-based leads rather than proven causes.

## Prerequisites

- A recorded session and the tester's expected and actual result

## Inputs

- A failing action with related requests and errors

## Outputs

- An evidence-backed investigation with explicit hypotheses

## Limitations

- Action associations are timing-based leads rather than proven causes

## Permissions

- Access to the recorded evidence

## Privacy

- Review logs and recorded values before copying or running artifacts

Start with the tester's expected and actual result, then trace the retained evidence around the failing action.

## Worked example: the sticky Blocked tag

Download and extract the [real sample bundle](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip). Open the recording folder described in [bundle structure](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle). This investigation uses the supplied files directly.

The application in this recording is Quackban, a card board on SpaceDucking. See [About Quackban and credits](https://fairleadhq.com/docs/recorder/schema/#about-quackban-and-credits) for attribution to Ministry of Testing and the MoTaverse creators.

### Establish the expected result

In `session.md`, QA expects moving a card out of Blocked to clear its Blocked tag. The recorded path creates `QB-DEMO sticky Blocked` in Pond Redesign, moves it to Blocked, then to In progress. The session starts at `2026-10-07T04:43:24.309Z` and lasts 42 seconds.

The description also mentions Done and a reload in earlier runs. Those are tester observations about other attempts: this recording does not contain those checks.

### Match actions to the HAR

Action offsets in `session.md` are relative to the session start. HAR `startedDateTime` values are absolute UTC times. Add the offset to the start to locate nearby traffic, then confirm the card ID and payload rather than relying on timing alone.

All HAR indexes below are zero-based; Markdown action numbers are one-based.

| Evidence | Time (UTC, 2026-10-07) | What to inspect |
| --- | --- | --- |
| Action 17: Clicked Blocked | `04:43:49.834` (+25.525s) | The first lane change. |
| `log.entries[2]`: POST | `04:43:49.837` | Move payload contains the card ID and `status: "blocked"`. |
| `log.entries[3]`: GET | `04:43:50.465` | Board response after entering Blocked. |
| Action 20: Clicked In progress | `04:43:56.535` (+32.226s) | The move that should clear the tag. |
| `log.entries[4]`: POST | `04:43:56.539` | Move payload contains the same ID and `status: "in_progress"`; no `blocked` field is sent. |
| `log.entries[5]`: GET | `04:43:57.141` | Board response after leaving Blocked. |

The move endpoint ends in `ef480cff6458da319ee4e576095f30ac06003e3931bf8be09ee209dea582919f`; the board endpoint ends in `e4c54e0e02fd6c771bbd5710d32e931705db77533c1189bdcba83ed643a2f8b2`. These are recorded application routes, not Recorder APIs or stable endpoint names for other builds.

### Read the serialized payload

In the HAR, parse `request.postData.text` and `response.content.text` as JSON for these entries. Their bodies use an application serialization format with parallel `p.k` (keys) and `p.v` (values) arrays. This wrapper belongs to the captured application, not HAR or Recorder's Report schema.

For the second move, `t.p.v[0].p.k` is `["id", "status"]` and `t.p.v[0].p.v[1].s` is `"in_progress"`. The card ID is `3229d3de-fb6d-4196-8f89-f0bf94d63392`.

In the last board response, `p.v[0].p.v[2].a` contains the cards. The sample card is at index 44. Match its ID when inspecting another capture; array positions can change. Within that card, key 4 is `status` and key 10 is `blocked`. The status value is `{"t":1,"s":"in_progress"}` and the blocked value is `{"t":2,"s":2}`, unchanged from the preceding board response. The initial board response has `{"t":2,"s":3}` for blocked. QA's note interprets this transition as false → true → true; use the application's serializer to decode these tags in application tooling.

Save this TypeScript as `inspect-sample.mts` in the extracted recording folder. With Node.js 24 or later, run `node inspect-sample.mts` to print the relevant raw fields without sending any requests:

```typescript
import { readFileSync } from "node:fs";

type EncodedField = { t: number; s?: string | number };
type EncodedCard = { p: { k: string[]; v: EncodedField[] } };

const { log: { entries } } = JSON.parse(readFileSync("network.har", "utf8"));
const cardId = "3229d3de-fb6d-4196-8f89-f0bf94d63392";
const move = JSON.parse(entries[4].request.postData.text);
console.log("move fields:", JSON.stringify(move.t.p.v[0].p.k));
console.log("new status:", move.t.p.v[0].p.v[1].s);

for (const index of [1, 3, 5]) {
  const body = JSON.parse(entries[index].response.content.text);
  const cards: EncodedCard[] = body.p.v[0].p.v[2].a;
  for (const card of cards) {
    const fields = Object.fromEntries(
      card.p.k.map((key, i) => [key, card.p.v[i]]),
    );
    if (fields.id.s === cardId) {
      console.log(index, fields.status.s, JSON.stringify(fields.blocked));
    }
  }
}
```

Expected output:

```text
move fields: ["id","status"]
new status: in_progress
1 backlog {"t":2,"s":3}
3 blocked {"t":2,"s":2}
5 in_progress {"t":2,"s":2}
```

This is a reader for this sample's payload shape, not a general HAR or application-protocol decoder.

### Separate the finding from the hypothesis

`screenshots/003-area.png` shows the card with a red Blocked badge. Its crop does not show the lane heading; use the action sequence and final board response for the In progress state. `002-full.png` shows an earlier state with the card in the Blocked lane.

The evidence supports investigating the lane-change update and the relationship between `status` and `blocked`. Check the application contract: should the server clear the flag when a card leaves Blocked, should the client send another field, or can the flag be managed independently? The missing field alone does not decide that design question or prove a database defect.

All six requests returned HTTP 200. No `console.log` is included, and the summary reports zero console errors. The creation payload is redacted. Record these limits, then inspect application code and add a [regression assertion](https://fairleadhq.com/docs/recorder/developers/playwright-export/#adapt-the-sample-recording) for the agreed behavior.

## Find the action in the bundle

Locate the action in the numbered **Recorded actions** section of `session.md`. Confirm its label, relative offset, and surrounding sequence. Use `steps.json` or a generated script when you need candidate selectors or converted input values. If the action is outside the [retained interval](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention), ask for the missing context or a focused new recording.

## Follow related traffic

Use the action's relative offset and the session start to locate nearby entries in `network.har`. Check method, URL, status, payload, response, and timing. Confirm the same subject with an identifier or value before treating the request as related.

Follow related console entries and available stack traces. Keep background requests, polling, and unrelated warnings in view: nearby activity can be coincidental.

## Treat associations as leads

Artifact relationships reconstructed from timestamps are leads, not proven causes. The bundle does not preserve the Viewer's inferred-link control or every association detail.

For example, a save action followed by a 500 response supports investigating that request. It does not by itself establish whether the failure originated in validation, a downstream service, or a separate concurrent operation.

## Test the explanation

Use [backend correlation](https://fairleadhq.com/docs/recorder/session-correlation/) where configured, or [reproduce the request](https://fairleadhq.com/docs/recorder/developers/reproduce-a-request/) in an appropriate test environment. Compare the evidence with application code and server logs before naming a cause.

## Leave a useful handoff

Record the failing action, relevant request and error timestamps, confirmed observations, and remaining hypotheses in the issue or investigation record. Cite filenames and HAR entry indexes so another reader can verify the reasoning. Ask the tester for a new `notes.md` or Description when missing context must be preserved in another bundle.

Missing bodies, redacted values, or absent earlier events limit the conclusion. State those gaps rather than treating missing evidence as proof of absence.

---

# Environment and performance evidence
Canonical: https://fairleadhq.com/docs/recorder/environment-and-performance/
Markdown: https://fairleadhq.com/docs/recorder/environment-and-performance.md

Read browser context and timing measurements alongside the recorded actions.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Read browser context and timing measurements alongside the recorded actions. Selected metrics are not a complete profiler; INP and CLS are not calculated.

## Prerequisites

- A recorded session open in the viewer

## Inputs

- Environment and timing evidence

## Outputs

- Context for a diagnostic handoff

## Limitations

- Selected metrics are not a complete profiler; INP and CLS are not calculated

## Permissions

- Access to the session

## Privacy

- Review captured content before sharing

Use environment and performance evidence to explain the conditions of an observation and choose the next diagnostic step.

## Inspect the environment

Open the [viewer](https://fairleadhq.com/docs/recorder/session-viewer/) and select **Environment**. Review available browser, device, page, and viewport context, plus **Language**, **Colour scheme**, **Connection**, and **Page load timing**. Add build, account role, test-data state, and any other conditions that Recorder cannot establish for your test.

Do not infer the deployed application build from the browser version. Record that reference separately in your test result.

## Read lifecycle and timing evidence

Open **Timeline** for FCP, LCP, long tasks, and other recorded performance events. Available lifecycle events can help explain page loading and navigation. Performance evidence includes First Contentful Paint (FCP), Largest Contentful Paint (LCP) observations, long tasks, and selected resource timings.

Long tasks use a 50 ms threshold. Resource evidence includes selected fetch/XHR, slow, cached, and render-blocking resources, subject to capture filtering. It is not an exhaustive resource inventory.

## Compare measurements carefully

FCP, LCP, and resource observers can supply buffered entries measured before Start. That does not mean Recorder captured the user actions that preceded Start. Check timestamps and the retained interval before relating measurements to your check.

Multiple LCP observations do not automatically give you a finalized page-level score. Browser support determines which entry types are available; absent metrics may be unavailable rather than zero.

## Investigate a delay

Compare available measurements with the action, [request timing](https://fairleadhq.com/docs/recorder/network/), and console errors. Keep network and device conditions stable across attempts, or document the differences.

Recorder does not calculate INP or CLS and does not provide a complete Core Web Vitals assessment. Use a browser profiler or dedicated measurement tool for deeper analysis and repeatable benchmarks. Follow [Investigate slow or unresponsive behavior](https://fairleadhq.com/docs/recorder/slow-or-unresponsive/) for the full workflow.

## Preserve the context

Include the relevant observed timings and environment in your handoff. The [download folder](https://fairleadhq.com/docs/recorder/bundle-contents/) is not an export of every viewer panel. Copy essential viewer-only context into your result; see [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes).

---

# Capture an exploratory discovery
Canonical: https://fairleadhq.com/docs/recorder/exploratory-testing/
Markdown: https://fairleadhq.com/docs/recorder/exploratory-testing.md

Preserve one exploratory observation, narrow its explanation, and carry a precise question into the next experiment.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use Explore to capture an observation, work backward through linked evidence, save the first discrepancy, and choose the next experiment.

## Prerequisites

- A focused browser experiment and safe data

## Inputs

- A question, variation, or unexpected observation

## Outputs

- A preserved discovery with evidence and one next question

## Limitations

- Explore has no Recorder result control, charter manager, or automatic coverage report

## Permissions

- Authorization to test the application

## Privacy

- Review evidence and authored questions before sharing

Use **Explore** when you are learning how a feature behaves, following an unexpected observation, or preparing a new defect that does not yet have a test case. Explore does not show a Recorder result selector: you write the observation, coverage, and next question yourself.

## Follow this 9-step path

1. Select **Explore**. Leave Issue empty for an unfiled discovery, or select an existing issue when the experiment already belongs there.
2. Name one variation and write its starting conditions and question in **Description**.
3. Select **Start recording**, try the variation, and capture the unexpected or informative state.
4. Select **Stop → Investigate** promptly so the discovery remains in the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
5. Start at the image or action nearest the observation and work backward through the same subject's input, request, response, and earlier state.
6. Preserve the first supported discrepancy and the strongest competing explanation.
7. Add source comments that separate observation from inference.
8. Write one next experiment that could change your interpretation; finish Description and preserve the files or send the finding.
9. Verify the handoff before **New recording** clears the local evidence.

## Understand the Explore fields

| Part | What happens | What you decide |
| --- | --- | --- |
| Issue empty | The recording remains unfiled; a configured tracker can later create an issue | Whether the discovery is ready to report |
| Existing issue selected | Recorder can fill an unchanged Title and offer its description | Whether to append the description and update or replace it at send time |
| Description | Holds this experiment's question, observation, evidence, and next step | What the recording establishes and what remains open |
| Result | No Recorder control appears | Use scoped prose; do not turn exploration into a blanket pass |
| Delivery | Download, tracker action, or Fairlead storage can be chosen | Where this discovery belongs and who can open it |

If Recorder offers **Add** for a found issue description, it appends the text to your current Description. It does not replace your notes or stay synchronized with the issue.

## Define a recognizable experiment

Use a distinctive safe record such as `QA-lanes-A3`, and record setup completed before Start. A useful experiment changes one relevant condition where practical: direct move versus move through Blocked, warm versus cold cache, or one role versus another.

For the [Quackban example](https://fairleadhq.com/docs/recorder/testing-workflows/#shared-example-quackban), ask: “After this card enters Blocked and moves to In progress, does the badge remain?” “The server fails to clear the flag” is an explanation to test, not the discovery itself.

If the observation occurred before Start, preserve a manual image if permitted and make a fresh attempt. Add the reference through **Screenshots & Attachments → Upload image** or **Paste image**. Note its source and original time; an image added after Stop is not capture-time evidence.

## Work backward from the observation

1. Open the discovery image and pin it. State exactly what it shows and which context it omits.
2. In **Actions → Recorded Actions**, inspect the preceding action's Target, captured value, control state, page changes, and URL changes.
3. Open the associated request. Check Payload for the subject and intended value; check Response or a later read for the resulting state.
4. Use Timeline and Timing to rule out an early screenshot or intervening update. Inspect Console or live messages only when they could explain the remaining discrepancy.

In the shared sample, the intended lane reaches the payload and returned status while the blocked-related node remains unchanged. That weakens “the click did nothing” and suggests a persistence/read question. HTTP 200 does not settle the observation.

Stop when you can explain the observation and name the uncertainty most likely to change that explanation. You do not need a root cause before preserving useful evidence.

## Choose the next experiment

| Remaining uncertainty | Next experiment | Preserve |
| --- | --- | --- |
| State may be transient | Reload the same record in a separate attempt | Before/after state, reload, and fresh read |
| Prior history may matter | Compare a direct move with a path through the prerequisite | Starting state and resulting records |
| A later update may restore old state | Keep the interval after the trigger | First read, later update, and later image |
| Repeated controls may be confused | Use a distinctly named record | Target context, sent ID, and visible subject |

Preserve the current recording before starting the comparison. A2 should identify the changed condition.

## Write and deliver the discovery

In Notes, use **View evidence → Add comment → Save comment**. Write `Observation → why it matters → open question`.

```markdown
Experiment: lanes / A3 — Blocked to In progress
Build / environment / role: [fill in]
Setup before Start: [fill in]
Variation tried: [fill in]
Observation: [specific result]
Evidence: [NOTES]
Coverage / gaps: [fill in]
Next experiment: [one question]
```

Insert Notes and resolve any save error. Keep a local download when the discovery is not ready to file; create an issue when it supports a report; update or replace a selected issue when it belongs there; or store the report with Fairlead when configured.

Open the files or destination. Retry only a failed issue, attachment, storage, or download operation. Preserve this experiment before any separate focused reproduction, then use **New recording**.

[Choose another testing workflow](https://fairleadhq.com/docs/recorder/testing-workflows/).

---

# Verify a fix
Canonical: https://fairleadhq.com/docs/recorder/fix-verification/
Markdown: https://fairleadhq.com/docs/recorder/fix-verification.md

Repeat the original failure on a candidate build, compare equivalent evidence, and add a Fixed or Not fixed result to the issue.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use Verify fix, compare original and candidate evidence, choose Fixed or Not fixed, and add evidence without implying an automatic issue transition.

## Prerequisites

- Recorder installed; candidate build and original issue available

## Inputs

- Original failure evidence and explicit verification criteria

## Outputs

- A Fixed or Not fixed result linked to new evidence

## Limitations

- Recorder does not diff recordings or change issue status automatically

## Permissions

- Authorization to test the candidate build and update the issue

## Privacy

- Review comparison evidence before downloading or sending

Use **Verify fix** when a candidate build is ready and the original issue defines what must change. Recorder requires the issue and offers **Fixed** or **Not fixed** after Stop. Keep the original evidence unchanged beside the new attempt.

## Follow this 10-step path

1. Select **Verify fix** and choose the issue being verified.
2. Review the fetched Title. If Recorder offers the issue description, choose **Add** only when appending it will help; it does not stay synchronized.
3. In **Description**, state the candidate build, original failure point, required criteria, and meaningful differences from the original conditions.
4. Select **Start recording** and repeat the original setup and trigger.
5. Capture the original failure point and any persistence check, then **Stop → Investigate** while both remain in the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
6. Compare the same logical subject across the action, sent data, returned state, and visible result; do not require identical IDs or encodings.
7. Add comments that pair the original observation with the candidate observation and name the criterion they settle.
8. Choose **Fixed** only when all required criteria are met; choose **Not fixed** when a required defect remains.
9. Finish Description, review privacy, and choose **Add evidence only** or a manual download.
10. Verify the issue comment and attachments, change issue status in the tracker yourself, and only then select **New recording**.

## Understand what Recorder does

| Part | Recorder | Tester |
| --- | --- | --- |
| Issue | Requires an issue lookup and stores its reference | Confirm it is the defect under test |
| Description | Can append fetched issue text when you choose Add | State the candidate build, criteria, result, and gaps |
| Comparison | Shows each recording separately | Keep the old evidence open and compare equivalent subjects/states |
| Result | Offers Fixed or Not fixed after Stop | Choose from the original acceptance criteria |
| Send | Offers **Add evidence only**; the automatic default action is locked | Update issue status or resolution manually |
| Blocked/inconclusive attempt | Has no matching verification result | Leave result unselected, preserve files, and update manually |

The primary send remains disabled until an issue and supported result are selected. Do not choose Not fixed merely to send a blocked or inconclusive attempt.

## Define the comparison

Prepare a small map before recording:

| Original evidence | Candidate evidence to capture |
| --- | --- |
| Meaningful reproduction path | Equivalent setup and trigger, with deviations stated |
| Important response or state | Same logical property on an equivalent test record |
| Failure image | Same observation point with enough subject/context |
| Relevant exception | Whether it recurs and whether the required behavior completes |

Recorder's Environment supplies browser/page context, not the deployed build. Record build, role, data shape, flags, and other application conditions yourself.

For the shared badge example, establish that the badge appears when the card enters Blocked, then verify it clears after leaving. Testing only that the badge is absent could miss a regression where it never appears.

## Follow the original discrepancy

1. In Actions, confirm the equivalent Target and prerequisite state.
2. In Payload, check the intended subject and change. A changed contract can be valid; compare meaning, not bytes.
3. In Response or a following read, locate the state that failed originally. Include a reload read when persistence is part of the criterion.
4. In Screenshots & Attachments, verify the expected visible result for the same subject.
5. Use Timeline/Timing for completion and later updates; use Console only when a relevant error changes the interpretation.

The sample archive supplies only failing evidence. A new recording must establish the candidate result.

## Decide the verification result

| Observation | Recorder result | Next action |
| --- | --- | --- |
| Original path completes and every required criterion is met | **Fixed** | Preserve positive state/data evidence |
| Required visible, returned, or persistent behavior still fails | **Not fixed** | Preserve where it first fails and any changed diagnostics |
| Access, data, build, or another prerequisite prevents the check | Leave unselected | Describe Blocked in Description; download and update manually |
| Path runs but decisive evidence is unavailable or ambiguous | Leave unselected | Describe Inconclusive and the observation needed next |

A corrected response with a wrong screen is Not fixed when the user-visible criterion remains. A corrected screen with required persistence still wrong is also Not fixed. Do not require an old internal field when the agreed behavior no longer depends on it.

## Write and send the comparison

```markdown
Verification: QB-17 / A1 / Fixed
Candidate build / environment: [fill in]
Original evidence: [issue and file reference]
Original steps: [repeated, with deviations]
Expected at failure point: [criterion]
Observed on candidate: [specific result]
Before / after evidence: [NOTES]
Additional checks: [separate results]
Unverified conditions: [list]
```

In Notes, use **View evidence → Add comment → Save comment**. State `Original → Candidate → criterion settled or unresolved`. Insert reviewed Notes into Description and resolve any save error before handoff.

For Fixed or Not fixed, choose **Add evidence only**. Recorder adds Description and the verification result as issue evidence; it does not close, reopen, or move the issue. The locked default-action choice is not available. Open the issue and confirm text and images, then perform the team's status change in the tracker.

For blocked or inconclusive attempts, review Privacy preview and **Download report**. Attach or summarize the result manually without choosing an inaccurate product result. Keep the new folder separate from original evidence.

Issue update, attachment, report storage, and download can fail independently. Retry the failed part; after an unknown timeout, inspect the issue before sending again. Preserve this attempt before another variant and use **New recording** only after the destination is usable.

[Choose another testing workflow](https://fairleadhq.com/docs/recorder/testing-workflows/).

---

# Install and open Recorder
Canonical: https://fairleadhq.com/docs/recorder/installation/
Markdown: https://fairleadhq.com/docs/recorder/installation.md

Add Fairlead Recorder to Chrome and open the side panel to start your first test.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Install Fairlead Recorder from the Chrome Web Store, pin it to the toolbar, and open the side panel; includes permissions and automatic updates.

## Prerequisites

- Google Chrome on a computer

## Inputs

- A browser application to test

## Outputs

- Fairlead Recorder installed and its side panel open

## Limitations

- Chrome internal pages cannot be recorded

## Permissions

- Website access and browser debugging for recording

## Privacy

- Record only pages and data you are permitted to capture


Install Fairlead Recorder in Chrome to capture browser test sessions, review the evidence, and download it. You can record locally without a Fairlead account.

## Install Recorder

Use Google Chrome on your computer.

1. Open [Fairlead Recorder in the Chrome Web Store](https://chromewebstore.google.com/detail/fairlead-recorder/njikgkpcbaaeoeaadbofdpakfkglhmjk).
2. Select **Add to Chrome**.
3. Review the requested permissions and select **Add extension**.

Chrome adds Recorder to your extensions. If your organisation manages Chrome and blocks installation, ask your IT administrator to allow Fairlead Recorder.

## Pin and open Recorder

1. Select the **Extensions** icon beside Chrome's address bar.
2. Select the pin beside **Fairlead Recorder** to keep it in your toolbar.
3. Open the application you want to test.
4. Select the **Fairlead Recorder** toolbar icon.

The Recorder side panel opens beside your page. Opening it does not start recording. Capture begins when you select **Start recording**.

You can use local recording, review, and downloads without signing in. To use your team's configured project and destinations, sign in to your Fairlead account.

## Understand the permissions

Recorder uses website access to capture actions on the page and browser debugging access to collect network requests, console output, and other diagnostic evidence. It also uses local storage to hold session data and Chrome's download support to save artifacts to your computer.

Record only pages and data you are permitted to capture. Before sharing a session, inspect its contents, including console messages and screenshots: automatic redaction does not cover everything.

## Keep Recorder updated

Chrome handles updates for extensions installed from the Chrome Web Store. If your organisation manages extensions, your IT administrator may control when updates become available.

Continue with [Recorder overview](https://fairleadhq.com/docs/recorder/overview/) for a tour of the controls and viewer sections, then [Record your first test](https://fairleadhq.com/docs/recorder/quick-start/).

---

# Create or update an issue
Canonical: https://fairleadhq.com/docs/recorder/issue-trackers/
Markdown: https://fairleadhq.com/docs/recorder/issue-trackers.md

Choose the session purpose, prepare Description, and send reviewed evidence to a configured tracker.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use Explore, Test case, or Verify fix to create, update, replace, or add evidence to an issue, then verify independent delivery outcomes.

## Prerequisites

- A connected project with a configured tracker destination

## Inputs

- Reviewed evidence, Description, and an issue choice supported by the session type

## Outputs

- A verified tracker mutation with attachment and storage outcomes

## Limitations

- Issue commands, attachments, report storage, and issue status changes are independent

## Permissions

- Project access and required tracker authorization through Control Plane

## Privacy

- Review content and destination before sharing

The tracker actions depend on the recording's session type. Your administrator configures the destination in Control Plane; Recorder never asks you to enter a tracker token or Bridge URL.

## Prepare the destination

[Sign in and select the project](https://fairleadhq.com/docs/recorder/projects/), then choose the appropriate session type:

| Session | Issue lookup | Supported tracker actions |
| --- | --- | --- |
| **Explore** | Optional; empty means a new issue | Create; or Update / Replace description for a selected issue |
| **Test case** | The field holds a test-case ID, not an issue | Failed/Blocked can Create issue or choose No issue; Passed has no issue action |
| **Verify fix** | Required issue | Add evidence only after Fixed/Not fixed is chosen |

For Explore or Verify fix, search or type the issue key. A found issue can fill Title when you have not intentionally changed it. Recorder offers **Add** when the issue has a description; Add appends the text to Description and records its origin. It never replaces your current text or remains synchronized. **Not now** leaves Description unchanged.

For Test case, TMS lookup is unavailable and the typed case ID is never sent as an issue header. A new issue created for a failure includes the case reference and selected result.

## Prepare Description

Description is the unified Markdown account for current local recordings. Include the attempt, build, expected/actual behavior, reviewed evidence, gaps, and next check. It saves after a pause or blur; resolve any save error before sending.

Older stored reports can contain a separate legacy reproduction-notes value. The current local Description editor does not edit that legacy field.

## Choose the send action

After Stop, open the split send menu. Picking an item only changes the primary button; nothing is sent until you press it.

- **Create issue** uses Title and Description.
- **Update ISSUE-123** adds Description as Fairlead's issue section and uploads supported screenshots; Recorder substitutes the selected key.
- **Replace description of ISSUE-123** makes Description the issue description. Use it only after checking current tracker text.
- **Add evidence to ISSUE-123** sends the verification result and Description as evidence. Recorder does not change issue status.
- **No issue** keeps a Failed/Blocked Test case from creating a defect.
- **Send data to Fairlead** stores the report without sending anything to the tracker or TMS.

Creating a linked issue and performing a default fix-verification transition are shown as locked **Soon** actions. They cannot be selected. TMS result delivery is also unavailable.

## Verify and recover

Open the resulting issue and verify its text and attachments. Issue creation/update, screenshot attachments, and report storage can succeed or fail independently. HAR files are not attached automatically; attach a reviewed file manually when needed.

Use a failed attachment's retry control when available. Do not create the issue again because attachment or storage failed. A timeout can leave the command outcome unknown, so check the tracker before retrying to avoid a duplicate.

Use **Download report** for a manual handoff or recovery. See [connection troubleshooting](https://fairleadhq.com/docs/recorder/troubleshooting-connections/) for missing credentials, project access, destination, or compatibility errors.

---

# Local recording and connected projects
Canonical: https://fairleadhq.com/docs/recorder/local-and-connected/
Markdown: https://fairleadhq.com/docs/recorder/local-and-connected.md

Choose where you record and how evidence reaches your team.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Choose account-free recording for local review and downloads, or a connected project for team capture rules and configured destinations. Sign in before starting a project recording.

## Prerequisites

- Recorder installed

## Inputs

- A browser test
- An assigned project for connected recording

## Outputs

- A recording workflow suited to your capture and sharing needs

## Limitations

- Signing in does not convert an existing local recording into a project session
- The retained timeline is bounded

## Permissions

- Website access and browser debugging for capture

## Privacy

- Review captured content before sharing

Use Fairlead Recorder without an account to record, review, and download evidence on your computer. Sign in before recording when you need your team's capture rules or configured sharing destinations.

## Choose your workflow

| What you need | Local recording | Connected project |
| --- | --- | --- |
| Account and project | No account required | Sign-in and an assigned project |
| Capture settings | Built-in local rules | Rules managed by your team in Control Plane |
| Evidence handoff | Download files, then share them yourself | Use the project's configured issue and report destinations |
| Backend correlation headers | Not sent | Available when configured for the project |

Both workflows use the same [retained-timeline and session limits](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).

## Record locally

Select **Continue without an account** on the sign-in screen. You can start and stop a recording, inspect it in the viewer, add screenshots and notes, and download artifacts to your computer.

Capture follows the hostname family of the page where you start; a leading `www.` does not create a separate scope. Local recording uses built-in capture and redaction rules, not your team's project settings.

Follow [Record your first test](https://fairleadhq.com/docs/recorder/quick-start/) to create local evidence. [Review it before sharing](https://fairleadhq.com/docs/recorder/review-redaction/), then [download the available artifacts](https://fairleadhq.com/docs/recorder/bundle-contents/). Downloading saves files to your computer; it does not submit an issue or upload a report to a project.

## Use a connected project

You need a Fairlead account and a project assigned by your administrator. [Sign in and select that project](https://fairleadhq.com/docs/recorder/projects/) before starting the recording.

The project's configuration controls capture domains, redaction rules, issue destinations, and report storage. Your administrator manages these settings in Control Plane; you do not enter issue-tracker API tokens in Recorder.

To save connected evidence on your computer, open **Investigate** and use the viewer’s **Download**. The connected side panel does not provide **Download report**. Review the evidence first; download begins without an additional acknowledgement.

Issue creation and updates go through the project's Bridge service to the configured tracker. Report uploads and enhancement use its Data Plane service. These operations have separate outcomes: a successful issue submission does not confirm that the report was stored.

Disabling report storage does not disable issue submission or screenshot attachments. Check [Storage and data destinations](https://fairleadhq.com/docs/recorder/privacy/) before sharing.

## Switch from local to project recording

A recording keeps the local or connected context it had when it started. Signing in after starting a local recording does not turn that recording into a project session.

1. Review and download the local evidence you want to keep.
2. Select **New recording** to clear the current session.
3. Sign in and select your project.
4. Start a new recording and perform the check again.

The new session uses the selected project's configuration. It does not include evidence from the previous local recording.

## When project setup is unavailable

If no profile is assigned, ask your Fairlead administrator to assign one. If a destination is missing, use [connection troubleshooting](https://fairleadhq.com/docs/recorder/troubleshooting-connections/). Local recording can still be used independently when that workflow meets your needs; it does not inherit the missing project's configuration.

---

# Navigation, tabs, and frames
Canonical: https://fairleadhq.com/docs/recorder/navigation-and-frames/
Markdown: https://fairleadhq.com/docs/recorder/navigation-and-frames.md

Understand which pages and embedded content belong to your recording.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Understand which pages and embedded content belong to your recording. Eligible new tabs are not all browser tabs; frame and Shadow DOM details can be incomplete.

## Prerequisites

- Recorder installed; target page open

## Inputs

- A flow across pages or frames

## Outputs

- Identified capture scope and evidence gaps

## Limitations

- Eligible new tabs are not all browser tabs; frame and Shadow DOM details can be incomplete

## Permissions

- Website access and browser debugging for capture

## Privacy

- Review captured content before sharing

Recorder follows supported navigation during capture, including single-page application URL changes. Page boundaries still matter when you review what was recorded.

## Start on the application page

Open the application before selecting **Start recording**. Local recording derives its capture scope from the starting hostname family. Connected projects use configured domain and network rules.

Keep a note of the starting page and any required login or application state. An exported initial navigation opens a URL; it does not recreate that state.

## Follow navigation and new tabs

Normal navigation and supported SPA transitions can appear in the action history. When the recorded tab opens a new tab, Recorder switches to it and stops capturing the original tab. This switch also happens when the new destination is outside capture scope, so the resulting evidence may be incomplete. Opening an unrelated tab does not switch capture. Closing the currently recorded tab stops the session.

Check the recorded page URLs after a cross-domain or new-tab step. If part of the flow lies outside the configured scope, describe that gap and ask the project administrator to review the [capture rules](https://fairleadhq.com/docs/recorder/capture-configuration/).

## Inspect embedded frames

Captured iframe actions include frame provenance. Values from untrusted frames may be omitted or masked; project configuration determines trusted-frame value capture.

When a frame's action looks incomplete, record its source URL and compare it with the configured trust and domain rules. Do not infer that the user left a field blank because its value is unavailable.

## Understand component boundaries

Recorder supports actions in open Shadow DOM and records selector alternatives where available. Closed shadow roots and inaccessible browser surfaces can limit the available target details. Generated tests may need manual locator changes for frames and components.

## Preserve the interval you need

Navigation does not extend the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention). The starting page shown for that interval can represent where the retained segment begins, even when earlier navigation has been evicted. Use [short checkpoints](https://fairleadhq.com/docs/recorder/test-execution/) for longer journeys.

---

# Network requests and responses
Canonical: https://fairleadhq.com/docs/recorder/network/
Markdown: https://fairleadhq.com/docs/recorder/network.md

Find a request and inspect its captured details.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Find a request and inspect its captured details. Bodies may be unavailable or truncated; HTTP status alone does not establish application success.

## Prerequisites

- A recorded session open in the viewer

## Inputs

- Captured requests and responses

## Outputs

- Relevant request details and identified gaps

## Limitations

- Bodies may be unavailable or truncated; HTTP status alone does not establish application success

## Permissions

- Access to the session

## Privacy

- Review captured content before sharing

Use **Network** in the session viewer to inspect traffic around a check. Start with the action and observed result so you know which request matters.

## Find the request

1. Open **Investigate** after stopping the recording.
2. Select **Network**.
3. Search for a URL, header, payload value, response text, or message.

Narrow the list with **Response status**, **Method**, or **Source**. **More filters** includes domain, exact status, duration, response size, and GraphQL filtering. Use **Type** to distinguish traffic such as WebSocket rows, **Attention** to narrow diagnostic findings, and **Hide data: URLs** or **Hide extension URLs** to reduce noise. **From** and **To** sliders isolate a time range. Use **Reset filters** if an expected request disappears from the list.

The **Only caused by action** filter uses inferred associations; it can exclude relevant traffic that has no recorded action link.

## Inspect request details

Select a request, then examine the relevant detail tabs:

- **Headers:** Request and response headers and general information.
- **Payload:** Request content and **Query String Parameters**.
- **Response:** Captured response content.
- **Initiator:** Available information about what initiated the request.
- **Timing:** Available phases and waterfall evidence.
- **Cookies:** Captured cookie details and available privacy controls. Values are initially masked; permitted review decisions can include originals in exports.
- **EventStream:** Captured stream messages where available.

Search within the request details to find a field. Add a [note](https://fairleadhq.com/docs/recorder/notes/) to a request or a specific field when it explains the result.

## Interpret failures

An HTTP failure, a transport error, and an application-level error are different observations. GraphQL responses can contain errors with HTTP 200; inspect the response instead of relying only on status.

Missing, redacted, or truncated bodies are evidence gaps. They can result from capture rules, size limits, streaming behavior, or browser availability. A missing response does not establish that the server sent no data.

## Example: a successful request with the wrong result

In the [real sample](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#worked-example-the-sticky-blocked-tag), the In progress click occurs at +32.226 seconds. The following POST sends the card ID and `status: "in_progress"`; the next board response changes the status but retains the blocked value seen after entering Blocked. All six requests returned HTTP 200. Inspecting only failed requests would miss this finding.

## Review an image response

For eligible uncaptured image responses in a local session, **Load from cache** attempts to read the browser's cached image. It does not request it from the origin server. If that fails, **Re-download image**, when offered, makes a new request to the displayed URL and may use browser cookies or follow redirects. It can return a different image from the one seen during recording; the preview shows when it was retrieved.

Use **Add as attachment** only after checking the image. Record that it was retrieved later if timing matters. Masked URLs cannot be re-downloaded, and these controls are unavailable in stored-session review.

## Reuse the request

Use [Copy and reproduce a request](https://fairleadhq.com/docs/recorder/developers/reproduce-a-request/) for cURL and HAR handoff. Review sensitive fields before copying or downloading. [Streaming traffic](https://fairleadhq.com/docs/recorder/developers/graphql-and-streams/) explains evidence that does not carry into a standard HAR.

---

# Add notes to evidence
Canonical: https://fairleadhq.com/docs/recorder/notes/
Markdown: https://fairleadhq.com/docs/recorder/notes.md

Explain an action, request, console entry, or screenshot where reviewers can find it.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Explain an action, request, console entry, or screenshot where reviewers can find it. Notes are saved as written; export includes saved annotations and pins.

## Prerequisites

- A local session open in the viewer

## Inputs

- An action, request, console observation, or screenshot

## Outputs

- Explicitly saved source-linked notes

## Limitations

- Notes are saved as written; export includes saved annotations and pins

## Permissions

- Access to the local session

## Privacy

- Review captured content before sharing

Attach a note to evidence when you need to explain an observation, expected result, or open question. Notes are available for local session review.

## Pin while investigating, explain when the finding is clear

Use **Pin** to keep a promising fact without stopping to compose a report. For example, pin the intended value in a move request, the corresponding returned state, and the screenshot of the wrong result. The three marks let you compare what was sent, what came back, and what was visible.

1. Open an action, request or log detail, or select an image in **Screenshots & Attachments**.
2. Pin the whole item with **Pin**, or right-click a specific field and choose **Pin** from its field actions. The mark saves immediately without opening an editor.
3. Continue following related evidence. A pin means “revisit this,” not “this is the cause.” Keep a useful earlier correct state as well as the failure.
4. Open **Notes**, select a pin and choose **View evidence** to check its source and surrounding context. Then **Add comment** on the pin, or use **Add note** at the source when the explanation is already clear.
5. Write what the evidence shows, why it matters, and any remaining uncertainty. Select **Important** for a deciding finding, then **Save comment**.

For the [worked sample investigation](https://fairleadhq.com/docs/recorder/bug-reporting/#find-the-deciding-evidence), an outgoing `in_progress` value establishes intended input; the following response establishes the retained blocked representation; the screenshot establishes the visible badge. Repeating “badge is wrong” on all three would lose those distinctions.

Notes are plain text and saved explicitly. Closing or cancelling an editor does not save its draft. Do not include passwords, tokens, or personal data; notes are saved as written. **Important** marks a finding but does not reorder notes or set tracker priority.

## Choose the source that supports the claim

Use a whole-action note for a reproduction precondition or manual observation. Use an exact-field note when a value or state is the evidence. Network supports headers, query parameters, JSON values and containers, raw body selections, cookies, initiator, timing and captured EventStream details. Action details support named target, captured-value, control-change and element/form-state fields. A field's context menu opens its note/pin actions; it does not open an editor until you choose the note action.

Application console and browser logs support message/stack and available detail-field notes. Older entries without stable identifiers explain why note creation is unavailable. Screenshots support notes directly on the image. Standalone Timeline lifecycle/performance rows, Environment and WebSocket messages do not have the same note editor; preserve useful facts from them in a related action note or Description, naming the source and time.

Check the preview before saving. It preserves bounded source context, so a note on a JSON key or short excerpt may not include the value or sibling that your conclusion needs. In the sample, the Important response note marks the key `blocked`; the explanation needs its paired value and the same card's status too. Use **View evidence** to verify those details and include the HAR when a developer needs the full record.

## Review and change notes

Open **Notes** for the session's saved annotations. Select a marked item, then **Edit comment** and **Save comment** to revise its text. **Delete comment** removes the comment while keeping the marked event; **Remove note** or **Remove pin** removes the marked item after confirmation. Existing notes can also be reopened from their evidence markers.

Select **View evidence** on the note card to return to its source. If **Evidence unavailable** appears, the target cannot be resolved; the note can still be edited or deleted.

If a save fails, the editor stays open with an error. Keep your text and resolve the problem before leaving. Concurrent edits from multiple viewers use the last saved change.

## Preserve notes for handoff

Download the session to save annotations in `notes.md`. It groups notes by source and includes available field paths, context excerpts, and **Important** markers. The file is omitted when no annotations exist. The [real sample](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) contains four notes, including a screenshot observation.

Use **Pin** on supported evidence to mark it without writing a comment. Empty pins are exported as “Marked without a comment.” In the local viewer's **Description**, **Add → Notes** inserts a copy of saved comments and bare pins into your narrative. Bare pins appear as “Pinned without a comment.” Later note edits do not update text already inserted; insert or edit it again as needed.

Check that your notes saved, then inspect `notes.md` before resetting. See [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes).

Notes saved in the viewer do not automatically become TMS result fields. Use [test outcomes](https://fairleadhq.com/docs/recorder/test-outcomes/) to record the assessment and evidence references.

---

# Recorder overview
Canonical: https://fairleadhq.com/docs/recorder/overview/
Markdown: https://fairleadhq.com/docs/recorder/overview.md

Find your way around the side panel, recording controls, and session viewer.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: A tour of Recorder's Explore, Test case, and Verify fix setup, recording controls, viewer tabs, results, and send destinations.

## Prerequisites

- Recorder installed in Chrome

## Inputs

- An application to test
- A stopped recording for exploring the viewer

## Outputs

- An understanding of where to record, inspect evidence, and prepare a handoff

## Limitations

- The retained timeline is bounded
- Available controls depend on recording state and project configuration
- Stored-session review differs from local review

## Permissions

- Access to the application and evidence being reviewed

## Privacy

- Review captured data before downloading, uploading, or submitting it
- Project generation sends the report to the configured Data Plane

Recorder has three places to work: the **side panel** beside your application, **in-page controls** while recording, and the **session viewer** for reviewing evidence. This tour explains where to go and what each section helps you do.

For a grouped list of keys for all three places, use the [keyboard shortcuts reference](https://fairleadhq.com/docs/recorder/shortcuts/).

You can record, review, and download locally without an account. Sign in and select a project before recording when you need your team's configured capture rules or sharing destinations. See [Local recording and connected projects](https://fairleadhq.com/docs/recorder/local-and-connected/).

## Side panel: prepare and control the recording

Open the side panel with the **Fairlead Recorder** icon in Chrome's toolbar. Opening it does not start capture.

### Choose the recording context

Use **Continue without an account** when you want to investigate locally and share downloaded files yourself. With no tracker connected, the title and description name and explain the local session; they do not create a ticket.

For a team workflow, sign in and select the assigned project before recording. That choice supplies the capture and redaction rules, issue destinations, and report-storage service. If the project has multiple tracker destinations, choose the one containing the issue you are testing. A missing destination is a project-configuration problem; a request to connect your personal tracker account is an authorization problem. Recorder directs you to Control Plane for that account connection.

Signing in after starting does not turn a local recording into a project session. Preserve it, then start a new recording in the intended project. See [Local recording and connected projects](https://fairleadhq.com/docs/recorder/local-and-connected/).

### Choose Explore, Test case, or Verify fix

The first row states what the recording is for:

| Session type | Lookup | Result after Stop |
| --- | --- | --- |
| **Explore** | Optional Issue; leave empty to prepare a new report | No Recorder result selector |
| **Test case** | Type the authoritative case ID; TMS search is unavailable | Passed, Failed, or Blocked |
| **Verify fix** | Select the issue being verified | Fixed or Not fixed |

For an issue lookup, Recorder can fill an unchanged Title and offers **Add** when the issue has a description. Add appends that text to Description; it does not replace your text or stay synchronized. Verify the issue key and use its link for full tracker context.

For Test case, keep the case open in the TMS. Recorder stores the typed ID but does not fetch instructions or synchronize the result. Attach reviewed evidence and enter the result manually. See [Testing workflows](https://fairleadhq.com/docs/recorder/testing-workflows/) and [TMS handoff](https://fairleadhq.com/docs/recorder/tms-evidence/).

### Record a focused attempt

Select **Start recording** when the application is ready for the check. The status and elapsed timer tell you whether capture is running. Perform the interaction, then select **Stop recording** promptly after the result appears.

Check the [retained-timeline and session limits](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) before starting. For a longer case, save short checkpoints and keep a separate account of the full execution. **New recording** clears the local session, so use it only after preserving the evidence you need.

### Add the visible result

While recording, use the in-page **Capture** or **Area** controls. After Stop, add existing files or clipboard images in the local Viewer's **Screenshots & Attachments** tab. Capture an error message or unexpected state while it is visible; Recorder does not create a screenshot for every action.

An image added after Stop can explain the result, but it does not recreate missing requests or actions. Images outside the frozen recording interval are not included in the report by default; review their inclusion controls. Local downloads can still contain those images, so check the actual screenshot folder before sharing it.

### Move from capture to review

After stopping, select **Investigate** to inspect the recording. Account-free sessions also offer **Download report** in the panel; connected sessions can download from the viewer. Downloading saves files to your computer. It does not create an issue or upload a report.

For a complete first attempt, follow [Record your first test](https://fairleadhq.com/docs/recorder/quick-start/).

## In-page controls: stay with the application

The recording toolbar lets you work without keeping the side panel open. **Capture** takes an image of the visible viewport; **Area** lets you select a region. **Panel** opens the side panel, and **Stop** ends recording. You can move the controls out of the way.

A viewport capture does not stitch together the whole scrollable page. Stopping freezes the retained timeline; taking another screenshot does not resume action or network capture. See [Screenshots and attachments](https://fairleadhq.com/docs/recorder/screenshots/) and [Start, stop, and reset](https://fairleadhq.com/docs/recorder/recording-lifecycle/).

## Session viewer: inspect and explain the evidence

After stopping, select **Investigate**. The viewer opens in an extension tab. Its sections answer different questions about the same recording; you do not need to inspect every tab for every test.

### Overview

Start here to decide what needs investigation before you hand off the recording. Evidence counts, review prompts, and items needing attention point you to failed requests, warning/error messages, or selectors that could make an exported test unreliable. Follow a prompt into the relevant evidence section. The viewer opens here when it detects failed requests, warning or error logs, or locator risks; otherwise it opens on Actions.

Readiness indicators help organize review. They do not establish that a test passed or that all sensitive information has been removed.

### Description and session context

Use Description to turn the capture into an account another person can reproduce: starting conditions, what you tried, expected/actual behavior, result, evidence, and gaps. The context above it shows the session type, available issue or test-case lookup, and selected result. Older stored reports can contain a separate legacy reproduction-notes value; current local recordings use Description.

Choose **Write**, **Split**, or **Preview** to edit Markdown, see text and its formatted result together, or read the result alone. Text saves after a pause and when you leave the field. A save error appears above the editor and marks the tab; resolve it before leaving. Saving the draft does not submit it to the tracker.

Use **Add** to bring evidence into the account:

| Menu item | What it adds | When to use it |
| --- | --- | --- |
| **Recorded actions** | The local action sequence and starting page, including custom action names. It includes actions regardless of the Actions tab's current filters. | Preserve the captured sequence without retyping it. |
| **Notes** | Saved notes and pins with their source context. | Bring the observations that explain the finding into the handoff. |
| **Steps to reproduce** | Generated numbered instructions. | Turn captured actions into a procedure the recipient can follow. |
| **Steps written by AI** | Instructions written from the recording using AI. | Produce a readable draft, then check its claims against the evidence. |

Inserted text goes at the cursor, replacing a selection when present; without a cursor in the field it goes at the end under a heading. **Undo** reverses the insertion. Inserting notes copies their current text into the account; review that text again if you later change the source notes.

Recorded actions and Notes insertion work locally. Both step-generation options require sign-in, a configured project Data Plane, and permission to save recorded data. The Data Plane is the project's service for report storage and processing. Deterministic generation sends a reduced report without network headers/bodies, logs, or attachments; AI generation sends the full report. Neither option is an offline operation.

**Improve → Rewrite with AI**, when available, rewrites the text already in the field. It differs from adding a source section: review the replacement and use **Undo** to restore the previous text if needed. Generation or rewriting can fail independently of local editing, so you can still write your own account.

This editor is not available for stored sessions opened from Control Plane. Use the separate Notes tab for observations attached to specific evidence.

### Actions

Use **Recorded Actions** for the sequence of interactions and **Event Log** for individual event details. Search the actions, inspect a target or selector, and follow available links to related requests and messages.

For a long list, use **Key actions only**, **Has evidence**, or **Needs attention** to narrow what you inspect, and **Group by page** to follow navigation. Filters change the view; they do not trim the exported recording.

Open an action to explain an ambiguous target, add a note or pin, and inspect its related evidence. **Rename** can replace a vague narrative with a clearer name; the original remains available, and renaming does not change the captured input or generated test commands. **Delete** is different: where allowed, confirmed deletion permanently removes the action from the report and exports. Actions anchoring related evidence are protected from deletion.

Use this view to answer “What did the tester do just before the problem?” Related evidence inferred from timing is a lead to investigate, not proof of causation. Earlier actions may be missing from the retained interval.

### Screenshots & Attachments

Inspect the images that show the visible result. Compare a screenshot with the action and request evidence, and review the available attachment controls before preparing a handoff.

For a badge or layout defect, use an area crop for the symptom and a wider image for the page context. Add a source-linked note to explain what the reviewer should notice.

Report inclusion affects the images sent with the report and tracker submission. Local downloads retain session images even when they are excluded from that report or outside its retained interval. An area crop may omit the lane or page heading, so compare it with the action and request evidence before drawing a conclusion. See [Screenshots and attachments](https://fairleadhq.com/docs/recorder/screenshots/).

### Tests

Preview generated **Playwright** and **Puppeteer** scripts, inspect locator risks, and download the format your developer needs. The full download also includes `steps.json` for Chrome DevTools Recorder.

Choose the format your team uses, inspect the preview, and copy or download it for the test project. Locator warnings identify selectors to check against the application rather than merely increasing a timeout.

For the sticky Blocked badge example, a script can successfully click both lanes and still miss the bug. A developer must add checks that the card reaches In progress and that its Blocked badge disappears. Generated actions also need authentication, test data, and stable locators before they become a reliable automated test. Local test generation is not available in stored-session review. See [Turn a recording into a reliable automated test](https://fairleadhq.com/docs/recorder/developers/reliable-automated-tests/).

### Timeline

Inspect the ordering and timing of captured events, including available lifecycle and performance evidence. Use it to compare an interaction with surrounding activity when investigating a delay or unexpected result.

For a slow interaction, compare the action time with the following requests and available long-task or paint events. This helps decide whether to investigate network delay, browser work, or the UI response. Check timestamps: some performance measurements describe page loading before recording began.

The timeline is not a video replay or a complete browser profiler. Its retained interval can be shorter than the elapsed session. See [Environment and performance evidence](https://fairleadhq.com/docs/recorder/environment-and-performance/).

### Network

Search or filter traffic and open a request to inspect its method, URL, status, headers, payload, response, and timing. Copy a request as cURL or HAR when a developer needs to investigate it separately.

Start with the endpoint and time associated with your check, then compare the submitted value with the returned one. In the [sample investigation](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#worked-example-the-sticky-blocked-tag), the lane-change request succeeds, but the following response still carries the blocked flag. That gives the developer a specific state-update question.

Search within a request to locate a value across detail tabs. Where captured, WebSocket frames and EventStream messages provide evidence for live updates. A missing response body may mean it was not captured or could not be retrieved; read the reason shown before assuming the server returned nothing. Copying as cURL prepares a request that may change data if executed, so review its destination and inputs.

A successful HTTP status does not establish correct application behavior. Read the body and compare it with the expected result. Missing, truncated, or redacted content limits what you can conclude. See [Network requests and responses](https://fairleadhq.com/docs/recorder/network/).

### Console

Review application messages, exceptions, and browser errors. Filter the entries and inspect available stack traces to connect a symptom with code or a request.

Use the level and source filters to separate an application exception from browser warnings. Compare its time and available stack trace with the relevant action or request, then add a note on the entry that explains its significance. This preserves the exact error for the developer instead of requiring them to search the entire log.

An empty console does not mean the test passed. Log text can also contain sensitive values that need review before sharing. See [Console and browser errors](https://fairleadhq.com/docs/recorder/console/).

### Environment

Read the recorded browser, page, viewport, language, colour scheme, connection, and available page-load context. Use it to explain the conditions under which the result occurred.

For a layout difference, compare viewport size, pixel ratio, and browser zoom between attempts. For slow loading, check the document-load timings and the browser-reported connection estimate. That estimate is context, not a measured bandwidth benchmark; the document load can also precede the route where you started recording.

Add application build, account role, and test-data preconditions separately when needed. A browser version does not identify the application build. See [Environment and performance evidence](https://fairleadhq.com/docs/recorder/environment-and-performance/).

### Notes

Review saved observations attached to evidence. Mark an observation as important, edit a comment or remove a note, or select **View evidence** to return to its source. Add notes while inspecting actions, requests, console entries, or other supported evidence.

Use **Pin** when you want to mark an event for follow-up without writing a comment yet. A pin and a comment are separate: you can add the explanation later, and a pinned event can remain after its comment is removed. Use **Important** for a note that the recipient should not miss. **Add → Notes** in Description brings these marked observations into the report narrative.

Keep observations specific: “Expected the badge to clear; this response still has the blocked flag.” Select **Save comment** to save note edits and check for errors. Notes are your written observations, so review them for sensitive information. See [Add notes to evidence](https://fairleadhq.com/docs/recorder/notes/).

### Privacy preview

Use this section to answer two different questions: “What sensitive values are included?” and “Is enough evidence present to explain the result?” The source ledger groups **Policy rules**, **Your decisions**, and **Not sanitized** report content. Select a source to inspect the values and records it affected, then follow links to the exact request, action, or log. Counts overlap when an overridden value appears under both its rule and your decision; an unavailable count is not zero.

In supported local evidence fields, right-click to open note and **Redact** or **Unredact** actions. Manual redactions change the reviewed report and generated artifacts; allowing automatically hidden originals into exports depends on the session policy. Some fields have no supported privacy control.

The **Originals** toggle has a different purpose: it shows or hides available original values locally and controls whether searches match them. Showing an original does not authorize its export; hiding it on screen does not redact the export. Review export decisions separately.

Use **Not sanitized → Recording composition**, **Truncated bodies**, and **Screenshots** to record gaps in the handoff. Redaction cannot recover bytes that were never captured, and field-level sanitization does not mask image pixels. Clicked-image thumbnails are included with action evidence and cannot be hidden in Privacy preview.

A clean summary is not a guarantee that the session is safe to share. Pay particular attention to written text and screenshot pixels. See [Review data before sharing](https://fairleadhq.com/docs/recorder/review-redaction/).

## Viewer header: name and preserve the session

Edit the title field in the header to name the attempt by check, build, or result. Press Enter or leave the field to save; Escape restores the previous title. The name also determines the folder for subsequent local downloads.

Choose the handoff that matches the recipient:

- **Download** saves the available evidence files locally. Check the actual files and Chrome download results before attaching them elsewhere. If some downloads fail, keep the session and retry.
- With a configured tracker, submit to create the new issue or update the selected one. Read the result, open the returned issue, and confirm the text and screenshots arrived.
- Report storage in the project Data Plane is a separate result. An issue can succeed while a screenshot or report upload fails; retry the failed operation rather than creating another issue. HAR files are not automatically attached by the tracker screenshot workflow.

If submission times out with an unknown outcome, check the tracker before retrying. For a TMS, attach reviewed files or an accessible link to the intended case/run and enter its result there.

**Return to recording** takes you back to the recording context; it does not resume a stopped capture. The viewer URL refers to extension-local evidence and is not a shareable report link. See [Open the session viewer](https://fairleadhq.com/docs/recorder/session-viewer/) and [Download session artifacts](https://fairleadhq.com/docs/recorder/bundle-contents/).

## Key facts before your first recording

- Capture begins at **Start recording** and follows the [retained-timeline limit](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention). Preserve short checkpoints for longer tests.
- Review and save the evidence you need before **New recording** clears the local session.
- Available controls depend on recording state, project configuration, and whether the session is local or stored. For remote review, follow [Open a stored session](https://fairleadhq.com/docs/recorder/stored-sessions/).
- Recorder supplies evidence; you decide whether the expected result was met. Record that assessment in your issue or [test result](https://fairleadhq.com/docs/recorder/test-outcomes/).

Continue with [Record your first test](https://fairleadhq.com/docs/recorder/quick-start/). If a section is empty, check that the recording has stopped and is still available locally; see [Recording and missing evidence](https://fairleadhq.com/docs/recorder/troubleshooting/).

---

# Browser permissions
Canonical: https://fairleadhq.com/docs/recorder/permissions/
Markdown: https://fairleadhq.com/docs/recorder/permissions.md

Understand why Recorder requests access to browser data.

Updated: 2026-10-08
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Understand why Recorder requests access to browser data. Browser policy and protected pages can prevent capture despite broad host permission.

## Prerequisites

- Google Chrome on a computer

## Inputs

- Recorder permission requests and target-page requirements

## Outputs

- An understanding of capture access and restrictions

## Limitations

- Browser policy and protected pages can prevent capture despite broad host permission

## Permissions

- Website access and browser debugging for capture

## Privacy

- Review captured content before sharing

Recorder needs website and browser debugging access to capture a test's actions, requests, and diagnostic messages. Use it only on pages you are permitted to test.

## What the permissions support

| Access | Purpose |
| --- | --- |
| Browser debugging | Capture network, console, exception, and related browser evidence |
| Website access and script injection | Record page interactions and support capture across eligible navigation |
| Tabs and navigation | Identify the recording tab and follow supported page transitions |
| Storage | Hold local session state and extension settings |
| Downloads | Write evidence files to your computer |
| Side panel | Keep recording and review controls alongside the page |
| Clipboard reading | Attach an image when you request a clipboard paste |
| Identity | Complete the Fairlead account connection flow |
| Alarms | Support background session activity |
| Offscreen document | Track browser color-scheme information for the toolbar icon |

## Website scope

Recorder requests broad all-site host access so it can operate on the test targets you choose. That browser permission does not override the recording's capture rules:

- **Without an account:** capture follows the starting page's **hostname family**.
- **Signed in with a project:** capture follows the restrictions your organization configures for the selected project, including page and network domain rules. Signing in does not bypass those rules.

See [capture configuration](https://fairleadhq.com/docs/recorder/capture-configuration/) for how these rules affect recorded evidence.

Capture begins after **Start recording**. Read [Navigation, tabs, and frames](https://fairleadhq.com/docs/recorder/navigation-and-frames/) for how scope affects the evidence.

## Restricted pages and files

Chrome internal pages and other protected browser surfaces cannot be captured. Local account-free recording also excludes `file:` pages. A connected capture of local files additionally depends on Chrome granting file access and on the project's rules.

A browser or organisation policy can prevent debugging or site access. If recording fails, review the reported error and ask the administrator responsible for that policy.

## Separate access from sharing

A browser permission enables capture; it does not decide which evidence you should send to a team. [Review the data](https://fairleadhq.com/docs/recorder/review-redaction/) and understand the [destination](https://fairleadhq.com/docs/recorder/privacy/) before downloading or submitting it.

---

# Storage and data destinations
Canonical: https://fairleadhq.com/docs/recorder/privacy/
Markdown: https://fairleadhq.com/docs/recorder/privacy.md

Know where local and connected session data goes.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Know where local and connected session data goes. Disabling report storage does not disable issue commands or screenshot attachment transfers.

## Prerequisites

- A local or connected Recorder workflow

## Inputs

- The intended download or submission operation

## Outputs

- Identified storage and data destinations

## Limitations

- Disabling report storage does not disable issue commands or screenshot attachment transfers

## Permissions

- Authorization for each destination used

## Privacy

- Review captured content before sharing

The destination depends on how you use Recorder. Local recording keeps its session in the browser until you download files; connected workflows can send content to your project's configured services.

## Local session data

Recorder holds session state in browser session storage and attachments in a local image store. Local session state can include original sensitive values used by privacy review, even where the viewer shows a mask. Treat this as working evidence, not a durable archive. Download what you need before resetting or ending your browser session.

**New recording** clears the previous local session, its attachments, and open local viewers. It does not delete files already downloaded or evidence already sent elsewhere.

## Downloads

The viewer’s **Download**, or **Download report** in the account-free side panel, writes artifacts to your computer. The files are then governed by your device, backup, and sharing practices. Local download does not create an issue or store a report on Fairlead's Data Plane.

Save the result in the description and download `session.md` with any `notes.md`. [Download session artifacts](https://fairleadhq.com/docs/recorder/bundle-contents/) explains their contents and conditional files.

## Connected destinations

| Operation | Destination |
| --- | --- |
| Sign in and load assigned project configuration | Fairlead Control Plane |
| Send correlation identifiers during connected recording | Request destinations reached by the recorded tab, including third-party origins; capture domain rules do not limit header injection |
| Search, create, or update an issue | The project's Bridge service and selected tracker |
| Attach screenshots to an issue | The configured tracker attachment path through Bridge |
| Store a session report | The project's Data Plane destination |
| Request report enhancement | The configured Data Plane enhancement service |
| Generate reproduction steps from Description | The configured Data Plane step-generation service |

Connected recordings send `x-fairlead-reproduction-id`; `x-fairlead-issue-id` and `x-fairlead-correlation-id` depend on their settings. This happens during capture, before report submission. Account-free recordings do not send these headers. See [backend correlation](https://fairleadhq.com/docs/recorder/session-correlation/).

In the local viewer, **Description → Add → Steps to reproduce** sends a reduced report to the Data Plane; **Steps written by AI** sends the full report. Neither is offline. **Recorded actions** and **Notes** insertion work locally. The description editor is unavailable for stored sessions. See [Generate user steps](https://fairleadhq.com/docs/recorder/steps-and-events/#generate-user-steps) for the fields sent by each mode.

Projects can use local, private, or cloud Data Plane configuration. Ask your administrator which endpoint and retention policy apply to your project.

## When report storage is disabled

The project setting **Save recorded data in Data Plane** disables report-bearing Data Plane operations, including enhancement and reproduction-step generation, when turned off. Issue commands and screenshot attachment submission may still send data.

Check the actual operation you are about to perform. Disabling report storage does not mean all connected data transfers are disabled.

## Review and retention

[Automatic redaction](https://fairleadhq.com/docs/recorder/redaction-rules/) does not cover every payload, console message, note, or image. Inspect content before sharing. Resetting a local session cannot recall external copies; use the destination's own retention and deletion process.

The [Fairlead Recorder privacy policy](https://fairleadhq.com/privacy/) explains local use without sign-in. The [platform Privacy Policy](https://fairleadhq.com/legal/privacy/) covers accounts and connected services.

---

# Sign in and select a project
Canonical: https://fairleadhq.com/docs/recorder/projects/
Markdown: https://fairleadhq.com/docs/recorder/projects.md

Load your team's recording rules and configured destinations.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Load your team's recording rules and configured destinations. Signing in does not convert an existing local recording into a project session.

## Prerequisites

- Recorder installed; a Fairlead account with an assigned project

## Inputs

- Browser sign-in or a fresh one-time connection token

## Outputs

- The intended project selected before recording

## Limitations

- Signing in does not convert an existing local recording into a project session

## Permissions

- Access to the assigned Fairlead project

## Privacy

- Review content and destination before sharing

Sign in to use a project assigned to your Fairlead account. Local recording remains available through **Continue without an account**.

## Connect through the browser

1. Open Recorder. If you are recording locally, select **Sign in**.
2. Select **Connect via browser**.
3. Complete the Fairlead sign-in flow in the tab that opens.
4. Return to Recorder and select the assigned project you need.

Check the project before starting: it determines capture rules and available destinations. Save existing local evidence before resetting to start a project recording.

## Use a one-time token

If your team uses connection tokens, obtain one from Control Plane, paste it into **One-time token**, and select **Connect**. Use a fresh token if the previous one expired or was already redeemed. Do not paste tracker credentials into this field.

## Check project availability

If Recorder says no profile is available, ask your Fairlead administrator to assign one. Signing in alone does not create a project or grant access to every project.

Administrators manage project domains, redaction rules, storage, and tracker destinations in Control Plane. Recorder loads that configuration; it is not a local project editor.

## Reconnect after expiry

Browser restart or an expired account session can require sign-in again. If a request rejects your session, reconnect and confirm the selected project before retrying.

A recording retains the context it had when started. Signing in after starting a local recording does not convert it into a connected session. See [Local recording and connected projects](https://fairleadhq.com/docs/recorder/local-and-connected/) and [connection troubleshooting](https://fairleadhq.com/docs/recorder/troubleshooting-connections/).

---

# Record your first test
Canonical: https://fairleadhq.com/docs/recorder/quick-start/
Markdown: https://fairleadhq.com/docs/recorder/quick-start.md

Capture a short browser check, review what happened, and save the evidence with your result.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Record a short test without an account, stop within the retained timeline, inspect the evidence, assess the result, and download local artifacts before starting a new recording.

## Prerequisites

- Recorder installed
- Target application open in the active tab

## Inputs

- A short check with an expected result
- Safe test data

## Outputs

- Reviewed local evidence files
- A tester-assessed outcome

## Limitations

- The retained timeline is bounded
- Test outcomes are assessed by the tester

## Permissions

- Website access and browser debugging for recording

## Privacy

- Review captured data before sharing; console messages and screenshot pixels are not automatically redacted

Record one short check, inspect the captured evidence, and save it with your test result. This guide uses local recording, so you don't need a Fairlead account or a connected project.

## Choose a check

[Install and open Recorder](https://fairleadhq.com/docs/recorder/installation/) first. Open the application you want to test and prepare safe test data.

Choose a short, focused check. The [real sample](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) uses this check:

> **Check:** Move a card from Blocked to In progress.
>
> **Expected result:** The card reaches In progress and its Blocked badge clears.

Use a check appropriate for your application. You can read the supplied sample without repeating its actions on the public site.

Keep the build, environment, and any test case or run reference in your test notes.

Recorder captures actions only after you start. Check the [retained-timeline and session limits](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) when planning your test. For a longer test, save separate recordings around meaningful checks; the elapsed timer does not show how much history is retained.

## Record the check

1. Open Recorder from the Chrome toolbar.
2. If the sign-in screen appears, select **Continue without an account**.
3. Select **Start recording**.
4. Perform your check and observe the result.
5. Select **Stop recording** as soon as you've observed the result. If the side panel has closed, select **Stop** in the in-page controls.

Stop promptly even when the check passes. Leaving capture running can push the actions you need outside the retained window.

If recording does not start, read the message in the panel and resolve the reported problem before repeating the check. Actions performed before capture starts won't be included.

## Review the evidence

Select **Investigate** in the side panel to open the session viewer. Start with **Overview**, then inspect the relevant evidence tabs.

- **Actions → Recorded Actions:** Check that the retained actions cover your test.
- **Network:** Inspect requests and responses relevant to the result.
- **Console:** Look for messages or errors that help explain what happened.

Compare the evidence with what you observed in the application. Missing events or responses are gaps in the recording; they don't prove an action never happened. A clean console alone doesn't mean the check passed.

Before sharing, review captured values, console messages, any screenshots, and your notes for sensitive data. Screenshots are not automatically masked. If the evidence contains information you cannot share, keep it private and repeat the check with safe data.

## Write down the result

Write the outcome in the viewer’s **Description** and keep the result in your test-management system when applicable. Description saves locally after a pause; check for a save error before downloading. Recorder supplies the evidence; you decide whether the expected result was met.

Use **passed** when the expected result was met, **failed** when it wasn't, **blocked** when you couldn't perform the check, or **inconclusive** when you couldn't determine the result.

The supplied recording supports this result:

```text
Check: Move QB-DEMO sticky Blocked from Blocked to In progress
Application: Quackban on SpaceDucking
Recorded: 2026-10-07 at 04:43:24.309 UTC; duration 42 seconds
Expected: The card reaches In progress and its Blocked badge clears
Actual: The final board response has status in_progress; the badge remains
Outcome: Failed against the stated expectation
Evidence: session.md action 20; network.har entries 4–5; screenshots/003-area.png
Limits: Application build not supplied; screenshot crop has no lane heading
```

Use **Add → Recorded actions** and **Add → Notes** to bring local evidence into the description. These insertions do not require an account.

Add your test case or run reference if you have one. If you skipped part of the check or the recording missed it, note the gap.

## Save the recording

1. Return to the Recorder side panel using its toolbar icon.
2. Select **Download report**.
3. Check that the files downloaded successfully. Download starts immediately; there is no additional privacy acknowledgement.

Chrome saves the artifacts in a folder under your download location. The available files include `session.md`, `network.har`, `steps.json`, generated scripts, and screenshot attachments. `notes.md` requires saved notes or pins; `console.log` requires console text. Read [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes), then confirm that your description and notes are present. This local download does not upload the recording or create an issue.

If some files fail to download, keep the session open and select **Download report** again to retry. Attach the reviewed files to your test run or share them through your team's usual channel, together with the result you wrote down.

Save the evidence before selecting **New recording**. Starting a new recording clears the previous local session and its open viewer.

---

# Start, stop, and reset
Canonical: https://fairleadhq.com/docs/recorder/recording-lifecycle/
Markdown: https://fairleadhq.com/docs/recorder/recording-lifecycle.md

Control capture and preserve the evidence you need.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Control capture and preserve the evidence you need. Capture starts on request and the retained timeline is bounded.

## Prerequisites

- Recorder installed; target page open

## Inputs

- A check ready to record

## Outputs

- A stopped session preserved before reset

## Limitations

- Capture starts on request and the retained timeline is bounded

## Permissions

- Website access and browser debugging for capture

## Privacy

- Review captured content before sharing

Start recording immediately before the behavior you want to check, and stop as soon as you have observed the result.

## Start from the side panel

Open your application and select **Start recording**. Recorder attaches to the tab and begins capturing supported actions and diagnostic evidence. Capture does not include actions performed before Start.

On Chrome versions that support closing the panel automatically, the panel closes and compact recording controls appear on the page. Use **Stop** to end capture, **Capture** to capture the visible viewport, or **Area** to capture a region. You can also reopen the panel. The timer shows elapsed recording time.

## Handle a pending start

If you start on a restricted page, Recorder may wait for navigation to an allowed page. Capture begins only when a suitable page is available. Select **Stop recording** to cancel the wait.

The selected project and capture settings are fixed for that start attempt. Changes made while waiting apply to a later recording. If the navigation lands outside the project's scope, the pending start is cancelled. Open an allowed page and select **Start recording** again.

<span id="stop-and-keep-the-last-two-minutes"></span>

## Stop and preserve the evidence

Select **Stop recording** in the panel or use the in-page stop control. See the [retained-timeline limit](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) for which part of the timeline remains.

The elapsed timer can show a longer duration than the retained evidence.

Stop promptly after an unexpected result. Continuing to browse can evict the actions that led to it.

## Review and save

Select **Investigate** to [open the viewer](https://fairleadhq.com/docs/recorder/session-viewer/). Review the evidence and [download local artifacts](https://fairleadhq.com/docs/recorder/bundle-contents/) or complete the available [project handoff](https://fairleadhq.com/docs/recorder/session-upload/).

Stopping does not itself upload the report. Screenshots outside the retained interval have separate inclusion controls; they do not reconstruct missing action or network history.

## Reset for another check

Select **New recording** only after preserving what you need. This clears the previous local session, its attachments, and open local viewers. Downloaded files and previously submitted evidence are separate copies.

For a long test, use short checkpoint recordings and keep their order in your execution summary. If capture fails or stops unexpectedly, see [Recording and missing evidence](https://fairleadhq.com/docs/recorder/troubleshooting/).

---

# How redaction works
Canonical: https://fairleadhq.com/docs/recorder/redaction-rules/
Markdown: https://fairleadhq.com/docs/recorder/redaction-rules.md

Understand automatic sanitization and the content that still needs review.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Understand automatic sanitization and the content that still needs review. Headers may be partially revealed; screenshots and console and notes need manual inspection.

## Prerequisites

- A recording or capture configuration to review

## Inputs

- Sensitive keys and captured content

## Outputs

- An understanding of sanitization coverage and gaps

## Limitations

- Headers may be partially revealed; screenshots and console and notes need manual inspection

## Permissions

- Project configuration access only when changing project rules

## Privacy

- Review content and destination before sharing

Recorder applies sensitive-value rules during capture and report assembly. Review the actual evidence before sharing because different content types have different protections.

## Sensitive keys and values

Password, passwd, and secret key matching is always applied. Account-free recordings also use baseline authorization, cookie, API-key, token, and session-key rules.

Connected projects supply their own sensitive-key and pattern lists. Those lists replace the local baseline; they do not automatically extend it. If the project omits `authorization` or `cookie` and no matching pattern covers them, those raw headers remain unmasked in stored reports and exports. Ask your administrator to include the keys your application uses.

Sensitive DOM inputs are marked for redaction, but original input values, network headers, and bodies can remain in local memory and the session-recovery snapshot. Untrusted iframe input-value capture is restricted. A masked display does not prove that an original was never captured.

Privacy review can mask supported fields. When revealing originals is permitted, preserving a field can include its original value in reviewed reports and exports. Account-free sessions permit this; connected sessions use the project policy captured when recording starts. Review those choices before downloading or sending evidence.

## Structured network content

Sanitization supports URL query parameters and JSON, URL-encoded, and multipart body paths. Matched headers can be partially revealed rather than entirely blanked.

Cookie values are masked in the initial reviewed projection. Supported privacy decisions can change the export when the session policy permits originals. Cookie fields and raw Cookie/Set-Cookie headers are related but distinct representations; inspect both after a change.

JSON that cannot be parsed is returned unchanged, including JSON cut off by a capture size limit. XML/SOAP and arbitrary free text have no universal redaction guarantee. Inspect their contents directly.

## Images and authored text

Console messages, screenshots, and notes require human inspection. Screenshot pixels are not automatically obscured. Notes are saved as written, so do not put secrets into an annotation.

Small clicked-image thumbnails can be stored with action evidence when an image-only control has no useful text. They remain in the export and have no removal decision in Privacy preview. Inspect the related action and repeat the recording with safe content when needed.

`session.md` and `notes.md` preserve your authored text. Captured evidence context follows the export review decisions; inspect both the context and what you wrote. Console text has supported manual redaction controls but no universal automatic secret matching.

## Check the rules used by your recording

[Understand capture rules](https://fairleadhq.com/docs/recorder/capture-configuration/) explains why page scope, trusted frames, and payload limits affect evidence. Ask your administrator about a project rule that causes a gap. New settings apply to a new recording; they cannot repair copies already shared.

The viewer does not provide arbitrary payload editing or pixel masking. Follow [Review data before sharing](https://fairleadhq.com/docs/recorder/review-redaction/) if a recording contains material you cannot send.

---

# Record a smoke or regression batch
Canonical: https://fairleadhq.com/docs/recorder/regression-testing/
Markdown: https://fairleadhq.com/docs/recorder/regression-testing.md

Work through an external smoke or regression list while preserving one identifiable result and evidence set at a time.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use Test case for each result, maintain an external run index, preserve retries separately, and complete the manual TMS handoff.

## Prerequisites

- Target build, authoritative case list, stable data, and Recorder installed

## Inputs

- Smoke or regression cases with expected results

## Outputs

- Per-case recordings and an external run index pointing to checked evidence

## Limitations

- Recorder is not a suite runner and cannot synchronize the batch to a TMS

## Permissions

- Authorization to test and update the external run

## Privacy

- Review each recording before attaching it to the run

Use **Test case** for every independently assessed case or checkpoint. Keep batch membership, order, skips, and completion in the authoritative TMS or worksheet. Recorder stores one case reference and one result per recording; it does not know whether the whole batch is complete.

## Follow this 10-step routine

1. Select the next case in the external run.
2. Choose **Test case**, enter its ID, and title the attempt with run/case/attempt/checkpoint.
3. Put the build, role, covered steps, and expected results in **Description**.
4. Select **Start recording**, execute only that case or checkpoint, and capture each decisive state.
5. Select **Stop → Investigate** while the useful path remains in the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
6. Verify each criterion against its action, data, and visible result; add source comments.
7. Choose **Passed**, **Failed**, or **Blocked**.
8. Finish Description, review privacy, download or send, and inspect the actual files/destination.
9. Enter the result and evidence reference in the external run manually.
10. Only after that row is complete, select **New recording**.

## Separate Recorder from the run system

| Concern | Recorder | External run |
| --- | --- | --- |
| Batch membership and order | Not stored | Authoritative |
| Test-case ID | Typed and stored; no TMS search | Identifies the case and result |
| Result | Passed, Failed, or Blocked after Stop | Must be entered manually |
| Attempt/checkpoint | Written in Title and Description | Tracks reruns and multi-recording cases |
| Evidence | Captured, annotated, downloaded, or sent | Holds the attachment/reference |
| Defect | Failed/Blocked can optionally create an issue | Keeps the issue link with the result |

The locked TMS destination means synchronization is unavailable. It is not proof that the TMS accepted anything.

## Choose recording boundaries

Record one short case or checkpoint at a time. A small smoke sequence can share a recording only when every check is identifiable and the complete useful sequence fits the retained interval. The timer can continue after early evidence is evicted.

For a long case, use `C1`, `C2`, and covered step numbers. For a rerun, increment A1 to A2 and keep the earlier result. A download retry for the same ready recording is not a new attempt.

```markdown
Run: R42
Build / environment / role: [fill in]
Case / attempt / checkpoint: TC-142 / A1 / C1
Covered steps and expectations: [fill in]
Result: [Passed / Failed / Blocked]
Observed: [fill in]
Evidence: [NOTES]
Follow-up: [issue or next checkpoint]
```

## Verify each result

For every expected result, confirm the intended Target and captured input, check Payload and Response or the following read when data decides the result, inspect the image with enough context, and use Timeline/Timing when ordering matters. Add a comment with `case / step / expected / observed` and save it.

Keep positive evidence for a pass. A clean Overview does not pass a case. Give a failure one focused investigation: locate the earliest supported discrepancy, save it, and decide whether the batch can continue. Similar warnings across cases do not establish one cause.

## Maintain a useful run index

| Case/check | Attempt | Result | Evidence reference | Follow-up |
| --- | --- | --- | --- | --- |
| TC-142, steps 1–4 | A1 / C1 | Failed | Folder plus badge image | QB-17 |
| TC-142, steps 1–4 | A2 / C1 | Passed | New folder and comparison note | Verification linked |
| TC-205, setup | A1 | Blocked | Summary and access error | Environment owner |

List checkpoint gaps and unexecuted cases externally. Recorder cannot infer them from existing recordings.

## Deliver, retry, and continue

Insert Notes into Description, review Privacy preview, and select **Download report**. Confirm completion and open the cited files. Enter the result in the TMS/worksheet and attach them.

Failed or Blocked can create an issue or choose **No issue**; Passed has no issue action. Report storage is separate. If a file fails, keep the ready session and retry. If TMS attachment fails, keep the folder and retry there. Do not select **New recording** until the run row points to evidence that opens.

Generated scripts need setup, assertions, and locator review; they do not replace the result or prove batch coverage.

[Choose another testing workflow](https://fairleadhq.com/docs/recorder/testing-workflows/).

---

# Review data before sharing
Canonical: https://fairleadhq.com/docs/recorder/review-redaction/
Markdown: https://fairleadhq.com/docs/recorder/review-redaction.md

Check captured content before downloading, uploading, or attaching it.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use the Privacy preview ledger to trace policy rules, your decisions, and unsanitized report content before sharing evidence.

## Prerequisites

- A recording or artifact ready for review

## Inputs

- Captured values and images and authored text

## Outputs

- Evidence selected for an approved destination

## Limitations

- Supported fields have manual redaction; screenshot pixels and authored text still need review

## Permissions

- Permission to access and share the selected evidence

## Privacy

- Review captured content before sharing

Review the evidence you intend to share, including images and text you wrote. Automatic redaction covers selected data structures and keys; it cannot make every recording safe to send.

## Review in eight steps

1. Stop the recording, select **Investigate**, then open **Privacy preview**.
2. Read the export-size estimate. Treat **partial estimate** as an attachment-storage gap, not as a complete size.
3. Start with the selected source, then inspect the other rows under **Policy rules**, **Your decisions**, and **Not sanitized**.
4. Search for the subject, field, or rule you care about. Use the treatment and field-type chips to narrow the evidence.
5. Select a source and open its affected values or records. Follow **Show in Network / Actions / Console** when you need the surrounding evidence.
6. Apply a supported privacy choice, wait for it to save, and confirm the exported status shown beside the value.
7. Inspect **Screenshots**, **Truncated bodies**, **Recording composition**, your notes, and Description separately.
8. Clear filters, review the final ledger and actual files or destination, then share only the evidence you intended.

## Inspect the stopped session

Open **Investigate**, then select **Privacy preview**. The toolbar estimates the export size and provides a search plus treatment and field-type filters. If attachment storage is unavailable, the size is marked **partial estimate**; missing previews do not prove that no images were captured.

The ledger groups the reasons behind the export:

| Group | What it answers | Important limit |
| --- | --- | --- |
| **Policy rules** | Which built-in or configured rule matched a captured value? | A configured rule comes from the recording profile; the Viewer does not identify whether it came from the project or a local default list. |
| **Your decisions** | Which values did you hide, preserve as originals, inherit from a hidden parent, or attempt to preserve when policy refused? | Empty decision types remain hidden unless selected. An unavailable group means local review metadata is missing, not that no decisions exist. |
| **Not sanitized** | Which screenshots, truncated bodies, and recording-composition data need separate review? | These entries describe gaps or content without field-level sanitization; they are not a privacy pass. |

Each ledger row shows **Values**, **Records**, **Hidden**, and **Visible**. A value you changed can appear under both its policy rule and your decision, so do not add the row counts into one total. Use the search and filter chips to narrow the ledger; every source row then shows its own match count. Select **Clear** to remove the search and filters.

Select a policy or decision row to see the values it affected. Expand its record rows when you need the request, action, or log that contained them. A value link opens the exact evidence in **Network**, **Actions**, or **Console**. A record opens its export JSON with treated values marked in place, followed by the decision details. On a narrow screen, use **Back to privacy sources** to return to the ledger.

Large lists show the first 100 records or values and offer **Show more records** or **Show more values**. A long export record can collapse unchanged lines around its marked values; **Show more marked values** expands the next group. These limits affect the rendered review list, not what the source count says was captured.

This view directs review; it is not a certification that all sensitive content has been removed.

Inspect the relevant actions, URLs, headers, payloads, responses, and cookies. Check console messages and stack traces separately. Read any notes and session descriptions you plan to copy into a handoff.

## Inspect images

Open **Not sanitized → Screenshots** to review available attachment previews and enlarge an image without leaving Privacy preview. Then open every screenshot or attachment you intend to share. Look at the pixels for names, account information, messages, credentials, or other sensitive content. Recorder does not automatically mask screenshot pixels or provide a pixel-redaction editor.

Small clicked-image thumbnails stored with actions are also exported. Privacy preview reports their count under **Screenshots**, but they cannot be hidden there. Open the relevant action to inspect its thumbnail. Repeat the recording with safe content when one cannot be shared.

Retake an image using safe data, or prepare and review an edited copy outside Recorder. Local downloads include images marked **Exclude from report** or **Outside recorded period**. Verify the actual files selected for sharing.

## Respond to sensitive content

In a local session, change a supported value either from its evidence detail or from Privacy preview. Evidence details use **Redact** and **Unredact**. The preview expresses the same choice as **Policy / Hide / Keep original**, **Default / Hide header / Keep header**, or **Export as captured / Hide**, depending on the value. A value hidden by a parent links to that parent instead of offering an ineffective child decision.

Keeping an original that a rule hides requires the session's reveal policy. When policy denies it, **Keep original** is disabled or the ledger records **Keep original refused**, and the export stays hidden. The control remains busy while Recorder saves the decision. If an inline error appears, resolve it before exporting; a successful update keeps the current source, filters, open record, and focus.

Console messages, stack traces, and individual arguments support manual redaction. Hiding a whole entry overrides its field choices until you restore the entry.

The **Originals** toggle only changes local display and search. It does not change export decisions. Use **Your decisions** to inspect **Hidden by you**, **Original kept**, inherited choices, and refused choices, then check the actual downloaded files.

**Delete** can permanently remove an eligible action from the report and exports; actions with linked requests or logs are protected. Filters only hide rows on screen. Neither feature provides arbitrary session trimming or a general payload editor.

If a field has no supported redaction control, use safe test data for a new recording or omit the affected artifact from a local handoff. Screenshot pixels and your own descriptions and notes still need manual inspection.

For local handoff, you can choose which downloaded files to attach. Removing a file from your intended handoff is different from sanitizing a connected report before upload.

## Review the destination

Local download saves files to your computer. Connected issue commands, screenshot attachments, report storage, and enhancement have their own destinations. Check [Storage and data destinations](https://fairleadhq.com/docs/recorder/privacy/) before submitting.

Both download entry points save immediately without an additional privacy acknowledgement. Review before clicking. Redaction changes to future exports cannot retract files or reports already shared.

A remotely opened or older report can show recording composition without the local rule/decision metadata. In that case the preview labels the estimate or controls as unavailable and does not offer privacy decisions. Review the supplied report as received and ask the recording owner for a newly reviewed export when required.

## Keep the result useful

After excluding sensitive material, state any resulting evidence gaps. Copy only reviewed observations; see [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes). See [How redaction works](https://fairleadhq.com/docs/recorder/redaction-rules/) for the automatic rules and their limits.

---

# Report structure and artifact formats
Canonical: https://fairleadhq.com/docs/recorder/schema/
Markdown: https://fairleadhq.com/docs/recorder/schema.md

Choose the right format before building a parser or integration.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Choose the right format before building a parser or integration. The sample ZIP contains local artifacts, not a serialized runtime Report.

## Prerequisites

- A report or artifact to inspect

## Inputs

- Runtime Report or HAR or action-export data

## Outputs

- The correct format and compatibility boundary

## Limitations

- The sample ZIP contains local artifacts, not a serialized runtime Report

## Permissions

- None declared.

## Privacy

- Review diagnostic content before sharing

Recorder uses different formats for assembled reports, HTTP archives, action flows, and generated scripts. Choose the format that matches the artifact you actually have.

For a normal developer handoff, start with [the shared artifact bundle](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/). The folder does not contain a serialized runtime Report. The Runtime Report section below is a format reference for a separately supplied report or integration.

## Runtime Report

The assembled report used for project storage and viewer data has these top-level fields:

| Field | Contents |
| --- | --- |
| `meta` | Report version, page URL, user agent, start/stop times, duration, title, description, notes, context, and session header identifiers |
| `http_requests` | HTTP and WebSocket diagnostic records |
| `console_logs` | Console entries and exceptions |
| `user_actions` | Recorded action events |
| `semantic_actions` | Grouped multi-event actions |
| `browser_logs` | Browser diagnostic messages |
| `lifecycle_events` | Page lifecycle observations |
| `performance_events` | Long-task, paint, and resource observations |
| `attachments` | Attachment records |
| `annotations` | Optional source-linked notes |
| `summary` | Event counts and diagnostic totals |

`meta.version` identifies the runtime Report format. Schema `1.37.0` adds optional workflow fields for compatibility with older reports:

| Field | Values and meaning |
| --- | --- |
| `meta.session_type` | `explore`, `test`, or `verify`: the selected session purpose |
| `meta.lookup` | The issue or test case as entered/found, with `id`, `found`, `source`, optional title, and optional URL; `null` when empty |
| `meta.result` | `passed`, `failed`, or `blocked` for Test case; `fixed` or `not_fixed` for Verify fix; `null` before selection and for Explore |

Read `meta.version` from the report you are consuming; do not substitute the extension version, HAR creator version, or sample ZIP filename. The sample ZIP does not include a runtime Report from which to read this value.

An optional `project_id` identifies ownership where supplied. A stored-session retrieval response may group records differently before the viewer assembles them into this report shape.

## Identifiers and timestamps

Report metadata contains `started_at`, `stopped_at`, and `duration_ms`. Event records use their own timestamps, including `@timestamp`; request timing has its own start information. Preserve the units and timezone of each field rather than comparing unlike values.

Issue and reproduction identifiers appear in report metadata; per-request evidence can include correlation identifiers. See [backend correlation](https://fairleadhq.com/docs/recorder/session-correlation/).

The stopped timeline follows the [retained-timeline limit](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention). Session duration and a starting timestamp do not prove the full elapsed session is present. Inferred action associations are not verified causal relationships.

## Local artifact formats

`network.har` uses HAR 1.2 HTTP structure. `steps.json` is Chrome DevTools Recorder action JSON. `playwright.spec.ts` and `puppeteer.js` are source code for their respective frameworks. `console.log` is text, `session.md` and `notes.md` are readable Markdown, and screenshot attachments are PNG files. The Markdown summaries are for handoff; use the structured artifacts for parsing requests and action flows.

The local download is not a serialized copy of every runtime Report field. See [Inspect a shared artifact bundle](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/) before choosing files for a developer handoff.

Inspect actual artifacts and handle unavailable or redacted content explicitly. Do not parse generated scripts as if they were a stable report API.

## Sample reproduction bundle

<span id="website-preview-sample"></span>

The [sample bundle ZIP](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip) contains a real reproduction: **Blocked tag stays after card leaves the Blocked lane**. Unzip it and start with `session.md` for the reproduction steps, expected result, and actual result.

The recording folder is named `Blocked tag stays after card leaves the Blocked lane-536bcb5d-e115-4676-aa62-21ddf3fb76c7`. Inside it:

```text
Blocked tag stays after card leaves the Blocked lane-536bcb5d-e115-4676-aa62-21ddf3fb76c7/
├── session.md
├── notes.md
├── network.har
├── steps.json
├── playwright.spec.ts
├── puppeteer.js
└── screenshots/
    ├── 001-area.png
    ├── 002-full.png
    └── 003-area.png
```

| Artifact | What this sample contains |
| --- | --- |
| `session.md` | Tester-written description and evidence, session start and duration, 21 numbered actions, and evidence counts. Read the description's conclusions alongside the captured files. |
| `notes.md` | Four source-linked observations: entering Blocked, the move request, the board response, and a screenshot. |
| `network.har` | HAR 1.2 with six entries in `log.entries`, all HTTP 200. The creation request and response bodies are redacted; later move payloads and board responses are available. |
| `steps.json` | A DevTools flow with `title` and 22 `steps`: viewport setup, initial navigation, and recorded interactions. Its step indexes differ from the numbered Markdown actions. |
| `playwright.spec.ts`, `puppeteer.js` | Generated actions using the recorded URL, values, and locators. They do not assert that the Blocked tag clears. |
| `screenshots/` | Three PNGs. `002-full.png` shows the card while it is in Blocked; `003-area.png` shows the card and badge without a lane heading. The `full` suffix denotes a viewport capture, not a stitched page. |

The ZIP also contains `__MACOSX/` and `._` metadata entries from archive packaging; ignore those when reading evidence. It has no `metadata.json`, serialized runtime Report, or `console.log`. Although `session.md` links to `console.log`, that file is absent. Its summary reports zero console errors; an absent file alone is not proof that no messages occurred.

These files were packaged as a ZIP for the website. The filename's `v1` is a sample download label, not a schema version for every enclosed artifact. Use each file's own format; for example, `steps.json` is a DevTools flow, not Fairlead Report JSON.

For a guided reading of the request bodies and timestamps, follow [the sample investigation](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#worked-example-the-sticky-blocked-tag).

The sample includes session and notes Markdown from the supplied recording; see [Inspect a shared artifact bundle](https://fairleadhq.com/docs/recorder/developers/artifact-bundle/) for their roles and omission rules. Files vary by recording and extension version.

## About Quackban and credits

[SpaceDucking](https://www.spaceducking.com/) is a testing resource created by [Ministry of Testing (MoT)](https://www.ministryoftesting.com/). [Quackban](https://www.spaceducking.com/apps/quackban), the Kanban-style application featured in this sample, was created within the MoTaverse, Ministry of Testing's community, and is available through SpaceDucking.

Credit for SpaceDucking and Quackban belongs to Ministry of Testing and the contributing MoTaverse creators. Fairlead used Quackban to demonstrate recording and investigating a bug with Fairlead Recorder.

## Compatibility

Keep the report's version with stored fixtures when building tooling. Validate the fields your consumer needs, handle optional fields, and test against artifacts from the extension version you support. Do not assume compatibility from one sample recording or rename files to make them fit another contract.

---

# Screenshots and attachments
Canonical: https://fairleadhq.com/docs/recorder/screenshots/
Markdown: https://fairleadhq.com/docs/recorder/screenshots.md

Add visual evidence to a recorded session.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Capture the visible viewport or an area during recording, then add and manage external images in the local Viewer.

## Prerequisites

- An active or stopped local recording

## Inputs

- A visible result or an image to attach

## Outputs

- Reviewed image attachments

## Limitations

- Capture records the visible viewport, not a stitched document; screenshots are not automatically masked

## Permissions

- Website access for capture; clipboard access when pasting an image

## Privacy

- Review captured content before sharing

Add a screenshot when an action or request alone cannot show the result. Screenshots are captured explicitly; Recorder does not create one for every action.

## Capture the visible page

While recording, the in-page controls offer **Capture** for the visible viewport and **Area** for a selected region.

1. Bring the application tab and the relevant content into view.
2. Select **Capture** to capture the visible viewport.
3. After Stop, check the image in **Screenshots & Attachments**.

Despite the control's label, this captures what is visible in the viewport. It does not scroll and stitch the whole document. To document content farther down the page, scroll to it and take another capture.

## Capture an area

Select **Area**, then choose the region of the visible page you need. Inspect the resulting image in the Viewer to confirm it includes the finding and enough context.

## Add an existing image

After Stop, open **Screenshots & Attachments** in the local Viewer. Use **Paste image** for a copied image or **Upload image** to choose a file. You can also drop images on that tab. If clipboard access fails, use the file route.

Record the origin of externally created images in your handoff. Their presence in a session does not establish when the pictured state occurred.

## Explain a screenshot

In the local viewer, open **Screenshots & Attachments**, select an image, and choose **Add note**. Write what the image shows and the expected result, optionally mark it **Important**, then **Save comment**. The note belongs to the image itself; you do not need to annotate a nearby action instead. Use **Notes → View evidence** to return to it.

## Review inclusion and timing

The Viewer marks images outside the stopped session's retained interval. Review their inclusion controls before submitting a report; an image from outside the interval may still be useful if you explain its timing.

Local downloads include all available attachments, including images marked **Exclude from report** or **Outside recorded period**. Those labels do not remove files from the download. Inspect the downloaded screenshot folder and share only the images you intend to send. Save needed images before **New recording**, which clears local attachments.

## Choose enough visual context

In the [real sample](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle), `002-full.png` shows the card in Blocked. The later `003-area.png` shows the retained badge but omits the lane heading. Use the recorded In progress action and final board response to establish the lane. For a new capture, include the destination lane heading with the card when that relationship is the finding.

## Check the pixels

Screenshots are not automatically masked. Inspect account names, messages, tokens, and other sensitive information before sharing. Use a separately reviewed edited copy or retake the image with safe data when needed. Recorder does not provide a pixel-redaction editor.

Privacy preview lists available attachments and lets you enlarge them under **Not sanitized → Screenshots**. It also reports small clicked-image thumbnails stored with action evidence. Those thumbnails remain in the export and cannot be hidden from Privacy preview; open the action to inspect one, and repeat the recording with safe content if necessary.

[Download session artifacts](https://fairleadhq.com/docs/recorder/bundle-contents/) explains the screenshot files saved alongside other evidence.

---

# Correlate with backend logs
Canonical: https://fairleadhq.com/docs/recorder/session-correlation/
Markdown: https://fairleadhq.com/docs/recorder/session-correlation.md

Connect a recorded request to application-side evidence.

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Connect a recorded request to application-side evidence. Account-free sessions do not send correlation headers; recorded IDs alone do not establish server receipt.

## Prerequisites

- A project configured to send identifiers; backend logging configured

## Inputs

- A captured request and backend logs

## Outputs

- Matched request evidence across browser and server

## Limitations

- Account-free sessions do not send correlation headers; recorded IDs alone do not establish server receipt

## Permissions

- Project configuration access and authorized backend log access

## Privacy

- Review diagnostic content before sharing

Use Fairlead identifiers to find backend logs for a recorded request. This requires a connected project and an application that accepts and logs the headers. Account-free recording does not send them.

## Distinguish the identifiers

| Header | Identifies |
| --- | --- |
| `x-fairlead-issue-id` | The selected issue, when enabled and supplied |
| `x-fairlead-reproduction-id` | The recording attempt |
| `x-fairlead-correlation-id` | An individual request, when enabled |

A reproduction can contain many requests with different correlation identifiers. Do not use one per-request ID as the identifier for the entire test run.

## Configure the application

Connected recordings send the reproduction ID with intercepted requests. Issue and per-request correlation IDs depend on their settings. Capture domain rules do not restrict header injection: requests from the recorded tab to third-party origins can also receive these identifiers. Review the application’s external requests before recording.

Have your project administrator configure the optional identifiers. Configure backend middleware to retain the incoming identifiers in request logs and, where appropriate, propagate diagnostic context to downstream services.

Check proxies and cross-origin configuration so the intended headers are accepted and preserved. Validate with a safe test request; do not assume a configured header reached the server merely because an identifier exists in the report.

## Find the matching logs

1. Open `network.har` from the supplied bundle in a HAR viewer or editor.
2. Find the relevant request and inspect its Fairlead identifiers and available request headers.
3. Search backend logs for the exact per-request correlation ID or reproduction ID.
4. Compare request URL, timestamps, environment, and response details.

If the required header was removed, redacted, or not included in the handoff, ask for the identifier or a newly reviewed artifact.

Account-free recording does not send these headers to the application backend. Locally recorded identifiers alone cannot locate server logs that never received them.

## Use existing trace headers

Project trace mappings can extract trace identifiers from configured request or response headers. Match the mapping to the application's actual tracing convention and use the extracted value with your existing observability tools.

A mapping records correlation evidence; it does not automatically configure middleware or provide a complete distributed trace.

## Diagnose missing matches

Check the selected project, identifier settings, and whether a proxy removed the header. Confirm the correct environment and log retention period, then inspect server logging itself.

If the application never logged the identifier, use the available URL and timing context and state the weaker association. Recorder cannot retroactively create backend correlation.

---

# Upload a session and enhance the report
Canonical: https://fairleadhq.com/docs/recorder/session-upload/
Markdown: https://fairleadhq.com/docs/recorder/session-upload.md

Use your project's report destination and check independent submission results.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use your project's report destination and check independent submission results. Issue success does not prove storage success; disabling report storage also disables enhancement.

## Prerequisites

- A connected project with recorded-data storage enabled

## Inputs

- A reviewed stopped session

## Outputs

- A checked report-storage or enhancement result

## Limitations

- Issue success does not prove storage success; disabling report storage also disables enhancement

## Permissions

- Project authorization for the configured Data Plane

## Privacy

- Review content and destination before sharing

Connected projects can store a session report in their configured Data Plane and request report enhancement. The project must permit recorded-data storage.

## Confirm the destination

Select the project before recording. Its Data Plane may be local, private, or cloud, as configured by your administrator. Confirm that the destination is appropriate for the evidence, then [review the data](https://fairleadhq.com/docs/recorder/review-redaction/).

A local account-free download saves files on your computer. It does not perform this project upload.

## Store the report

After stopping and reviewing the recording, select **Send data** in the side panel to upload the current report without creating or updating an issue. Check the upload result. If storage fails, resolve the reported error and retry **Send data**.

Issue submission also attempts report storage after the issue command and screenshot attachments. Review the storage result separately from the tracker result. After a successful upload through that submission flow, subsequent submissions in the same view skip storage. Later edits are not automatically synchronized; use **Send data** to send the current report again.

If the issue succeeds and report storage fails, keep the issue reference and resolve the storage error. Do not recreate the issue to repair its stored-session evidence. Ask your administrator to check destination availability and authorization before a storage retry.

## Request enhancement

After stopping, select **Enhance with AI** in the side panel when available. In the local viewer, use **Improve → Rewrite with AI** in Description. This explicitly sends report content through the project's configured Data Plane enhancement service.

Review the proposed text against the actual evidence. Correct unsupported causes, missing preconditions, and inaccurate outcomes before using it in an issue. Select **Stop enhancing** to cancel an in-progress request; cancellation does not retract data already sent.

## Understand disabled storage

When **Save recorded data in Data Plane** is disabled for the project, report upload, enhancement, and [reproduction-step generation](https://fairleadhq.com/docs/recorder/steps-and-events/#generate-user-steps) are unavailable. Issue commands and screenshot attachments may still be sent through the configured tracker connection.

## Verify the handoff

Check the issue, attachment, and storage results individually. Open the stored session from Control Plane when available. A successful issue submission alone does not establish successful report storage. See [Open a stored session](https://fairleadhq.com/docs/recorder/stored-sessions/) and [connection troubleshooting](https://fairleadhq.com/docs/recorder/troubleshooting-connections/).

---

# Open the session viewer
Canonical: https://fairleadhq.com/docs/recorder/session-viewer/
Markdown: https://fairleadhq.com/docs/recorder/session-viewer.md

Use each viewer as a different angle on one recording, follow linked evidence, and preserve your findings.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use each viewer as a different angle on one recording, follow linked evidence, and preserve your findings. The viewer is a snapshot; reset clears local evidence; its URL is not shareable.

## Prerequisites

- A stopped local recording

## Inputs

- Recorded actions and diagnostic evidence

## Outputs

- A reviewed session

## Limitations

- The viewer is a snapshot; reset clears local evidence; its URL is not shareable

## Permissions

- Access to the local recording

## Privacy

- Review captured content before sharing

Open the session viewer to connect what happened on screen with the actions and data behind it. Follow the evidence until you can explain the result or name the next check. Local review works without a Fairlead account.

## Open the recording

1. Select **Stop recording** when your check is complete.
2. Select **Investigate** in the side panel.

Recorder opens an extension tab for the session, or focuses its existing viewer. The side panel may close as review moves to the new tab.

## Choose the evidence

The viewer shows the same recording from different angles. Start from a known symptom, action, or error and follow the connections that answer your question. For example: **image of wrong state → action that should change it → submitted value → returned state → note explaining the discrepancy**. This is a reading path, not a mandatory tab order.

The viewer opens on **Overview** when it detects failed requests, warning/error logs, or locator risks; otherwise on **Actions**. Overview's metrics open the corresponding evidence. Its checklist and readiness text help organize review; they do not decide whether the application behaved correctly. A silent data defect can have no flagged errors.

| View | Question it helps answer | What to do with the answer |
| --- | --- | --- |
| **Actions → Recorded Actions** | What did the user try, and what changed around that action? | Select an action, inspect its target/state, and open its requests, logs, or screenshots. Identify the first discrepancy. |
| **Actions → Event Log** | Which captured events make up that interaction? | Inspect technical event types and times when keyboard actions, repeated clicks, or navigation need explanation. One user step can produce several events. |
| **Screenshots & Attachments** | What was actually visible? | Open the image, confirm identity and context, then attach an observation to it. Compare before/after images when available. |
| **Network** | Did the intended data leave the browser, and what came back? | Compare the same record across a write and following read, or across successive updates. Include requests without an action link. |
| **Console** | Did page code or the browser report something relevant? | Inspect message, stack, source and available arguments; connect the log to the same operation and time before treating it as a lead. |
| **Timeline** | In what order did actions, requests, page events, logs and images occur? | Check whether the proposed explanation fits the sequence; open any event's detail without leaving the chronology. |
| **Environment** | Which captured conditions could explain a difference between attempts? | Compare browser, viewport/zoom, language, colour scheme and connection context. Add the application build, role and settings yourself. |
| **Notes** | Which observations have survived the investigation? | Revisit pins, verify sources, write explanations and identify the decisive findings. |
| **Description** | Can another person follow the result without repeating my investigation? | Read the session type, lookup and result context; assemble minimal steps, expected/actual, evidence and open questions. |
| **Tests** | Can the captured actions help reproduce this later? | Review script and locator risks, then give a developer the expected checks that need assertions. Viewing a script does not execute a test. |
| **Privacy preview** | What will be shared, and which gaps or privacy choices affect the evidence? | Follow entries back to their sources, inspect the export decisions, and preserve a truthful account of missing evidence. |

## Read an action as intent, state, and related activity

In **Actions → Recorded Actions**, select the action nearest the result you are investigating. Read the available detail sections in this order:

1. **Target** identifies the actual control: visible text, label, role, element, selector, frame and available group context. Use these to distinguish repeated buttons or the same label in different rows. A readable label is a clue; check the subject rather than assuming the label uniquely identifies it.
2. **Captured value** and **What changed** show recorded input and before/after control changes. If you intended to check a box, this is stronger evidence than a click alone. It still does not prove the application saved that value.
3. **Element & form state** supplies captured state such as disabled, read-only, busy or form validity when available. This helps investigate “clicked but nothing happened.” An absent field does not mean the state was false.
4. **Page changes** describes captured DOM reaction; **URL changed** gives the recorded destination or query change. Use these to see whether the page reacted or changed context. A DOM change count cannot tell you whether the business result is correct.
5. **Related activity**, the request/log counts, and screenshot counts connect the action to other evidence. Select a request or log to open its details beside the action. Use its **Open in Network tab** or **Open in Console tab** arrow when the question needs the wider stream.

A **Clicked image** thumbnail identifies an image target; it is different from a captured screenshot of the page. Screenshot association is based on time and needs the same identity/context check as a request association.

**Cause** on a request or an associated console entry leads back to a likely action. **Back** in the viewer header returns to the previous view after supported evidence navigation. **View evidence** in Notes returns to the saved source. These routes let you examine one fact from another angle without rebuilding the whole investigation. Associations can be inferred from timing, so verify the record, operation and sequence yourself.

For keyboard investigations, turn **Key actions only** off; it hides keydown events. Event Log also hides scroll events by default. When evidence seems absent, inspect the broader view before concluding it was not captured.

If repeated generic action names make the sequence hard to follow, use **Rename** in a local action's detail, write a short purpose such as `Move affected card to In progress`, and **Save**. The original narrative remains visible; Event Log and Tests retain the captured data. Names also help when inserting recorded actions or notes into Description. Use **Restore** to return to the original name. To shorten the final reproduction, edit the inserted description: **Delete action** permanently removes the action and its notes from the recording and exports.

## Read a request as one part of an operation

Select an HTTP request from Actions, Network, Timeline or a saved note. The same detail views serve different questions:

| Detail | Inspect when… | Decision it supports |
| --- | --- | --- |
| **Headers** | You need to confirm destination, method, status, content type, request/response headers, or recorded failure information. | Is this the intended operation? Was it canceled, blocked, redirected, or served from a recorded cache source? HTTP success alone does not establish correct data. |
| **Payload** | You need the sent record ID, changed value, body or query parameters. | Did the browser express the user's intent? An omitted property raises a contract question; it does not establish which layer should supply it. |
| **Response** | You need the returned data or application error. | Did the result match the request and expectation? A short acknowledgement may require inspecting a subsequent read. GraphQL errors can accompany HTTP 200. |
| **Initiator** | You need the available script/stack origin to help a developer locate the request path. | Preserve the useful frame or function context, keeping the UI's **inferred** qualification. It is not a server trace. |
| **Timing** | You need start, end, duration, request phases, or linked browser resource timing. | Did the request finish before the wrong state was captured? Is the delay within the request or still visible afterwards? Missing phases are not zero durations. |
| **Cookies** | Login/session behavior may differ between attempts. | Compare recorded request/response cookie presence and attributes. Header links lead here; a masked value is not an absent cookie. |
| **EventStream**, when present | The page receives server-sent updates after the HTTP response begins. | Compare event time, identity and data with the visible update; the initial HTTP status does not describe every later message. |

A WebSocket row instead shows captured messages with direction and time. Read them when a live update may explain a state change without another HTTP response. Preserve a relevant safe excerpt and its time in your description; this view has no frame-note control, and standard local downloads do not include WebSocket frames.

Identify repeated requests by time and record, not URL alone. When a body is unavailable, read the displayed reason. Truncated, redacted and uncaptured content are different gaps. **Load from cache** and **Re-download image**, when offered for an image response, retrieve an image later; record that later provenance instead of treating it as a screenshot of the original failure.

## Check chronology and conditions

Use **Timeline** to ask “could these events explain each other?” It includes captured lifecycle and performance events as well as actions, requests, logs and screenshots. Open a lifecycle entry to inspect the navigation, frame, visibility or viewport context available for that event. Open a long task or paint/resource entry for its recorded timing and attribution.

A request row is positioned at its **start**, not completion. Check its **Timing** end before claiming a screenshot follows the response. Linked browser resource timing can appear inside that request's Timing tab rather than as a duplicate Timeline row. Copy a useful standalone performance/lifecycle observation into an action note or Description; those standalone details have no note editor of their own.

**Environment** describes initial conditions and the document open when recording began. Its document load may precede Start, and its connection tier is a browser estimate. Neither measures the time taken by a later click. Use a [focused responsiveness investigation](https://fairleadhq.com/docs/recorder/slow-or-unresponsive/) when those distinctions matter.

## Preserve the reasoning, then prepare the handoff

Right-click a useful field → **Pin** while following a lead. Later, select it in **Notes**, choose **Add comment**, explain what it shows and why it matters, and **Save comment**. Use **View evidence** to check the target and surrounding data. Notes on an action, field and screenshot answer different questions; combine them into a short explanation rather than repeating the same sentence on each. See the [worked investigation](https://fairleadhq.com/docs/recorder/bug-reporting/#find-the-deciding-evidence).

Use **Description → Add → Notes** after the comments are final. The inserted text includes source context, but is a copy and does not follow later note edits. Above the editor, Recorder shows available session context: Explore, Test case, or Verify fix; the issue/test-case lookup; and a selected result. Add preconditions and expected/actual behavior yourself. Older stored reports can contain a separate legacy reproduction-notes value, but the current local editor uses Description.

Open **Tests** when the action sequence is worth reusing. In the Playwright preview, select a highlighted line or **Review locator** card to inspect its recommendation and **Technical locator details**. Locator risks concern repeatability; they are not proof that the original action failed. A generated script still needs setup and assertions for the result your notes describe. Puppeteer is available when generated; full downloads also include DevTools Recorder steps.

In **Privacy preview**, use the source ledger to separate **Policy rules**, **Your decisions**, and **Not sanitized** content. The ledger shows value and record counts plus what is hidden or visible in the export. A changed value can appear under both its rule and your decision, so do not add the rows into one total.

Select a rule or decision to inspect its values and affected records. Open a record to see its export JSON with treated paths marked, or follow **Show in Network / Actions / Console** to the exact evidence. Search and treatment/field chips narrow every level and show per-source match counts. **Screenshots**, **Truncated bodies**, and **Recording composition** expose image, completeness, and unsupported-field gaps. The **Originals** display toggle still changes local display/search rather than export decisions. See [review before sharing](https://fairleadhq.com/docs/recorder/review-redaction/).

For a local/new report, edit the header title and press Enter to save. Keep an existing connected issue's fetched title unless you intend to rename it. Use **Download** to preserve reviewed files, or the configured issue action for connected handoff. Check the resulting files/text/attachments before resetting.

## Return to the application

Select **Return to recording** to return to the recording context. You can also select the application's tab and open the Recorder side panel from the toolbar. Returning does not resume a stopped recording.

## Preserve the session

The viewer loads a snapshot of the stopped report. Saved notes, session details, and supported review changes update the local view, but it is not a live recording stream. Reload after attachment changes made elsewhere before downloading.

[Download evidence](https://fairleadhq.com/docs/recorder/bundle-contents/) before selecting **New recording**. Reset clears the local session and its open viewers; the viewer URL is not a shareable report link.

If the viewer is empty, confirm a local recording is still available. Missing attachment or test-preview data can affect those sections while the rest of the report remains readable. For a session opened from Control Plane, see [Open a stored session](https://fairleadhq.com/docs/recorder/stored-sessions/).

---

# Keyboard shortcuts
Canonical: https://fairleadhq.com/docs/recorder/shortcuts/
Markdown: https://fairleadhq.com/docs/recorder/shortcuts.md

Use the keyboard to control Recorder, move through evidence, and edit a session.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use Recorder's contextual keyboard controls in the side panel, in-page toolbar, and session viewer. Recorder has no global start, stop, or screenshot shortcut.

## Prerequisites

- Recorder installed in Chrome

## Inputs

- A Recorder control or evidence view with keyboard focus

## Outputs

- Faster keyboard navigation and evidence review

## Limitations

- Recorder has no global start, stop, screenshot, or open-panel shortcut
- Shortcuts act only in the stated context

## Permissions

- Access to the recording or session being reviewed

## Privacy

- Keyboard actions performed in the tested page can become recorded evidence

Recorder's shortcuts are contextual: first move focus to the side panel, in-page controls, or session viewer, then use the keys listed for that control. Recorder does not register a Chrome-wide shortcut to open the panel, start or stop recording, or take a screenshot.

Use **Tab** and **Shift+Tab** to move between controls. Use **Enter** or **Space** to activate the focused button, tab, or button-like evidence row unless a more specific behavior is listed below. Use **Space** to toggle a focused checkbox.

## During recording

### In-page controls

| Focus | Keys | Result |
| --- | --- | --- |
| **Move controls** grip | **Enter** or **Space** | Open the menu for docking the controls to an edge. Press the same key again to close it. |
| Dock menu | **Up Arrow** or **Down Arrow** | Move through the four edge choices, wrapping at either end. |
| Dock menu | **Home** or **End** | Move to the first or last edge choice. |
| Dock menu | **Escape** | Close the menu and return focus to **Move controls**. |
| Dock menu | **Tab** | Close the menu and continue to the next focusable control. |
| Area screenshot overlay | **Escape** | Cancel the area selection without creating the screenshot. |

The focused **Capture**, **Area**, **Panel**, **Stop**, and close controls use the usual **Enter** or **Space** activation. There is no single-key screenshot or stop command when focus is elsewhere.

### Side panel setup

| Focus | Keys | Result |
| --- | --- | --- |
| Issue lookup | **Up Arrow** or **Down Arrow** | Move through the visible issue suggestions. |
| Issue lookup | **Enter** | Choose the highlighted suggestion. When no suggestion is highlighted, the stopped-session lookup uses the typed ID. |
| Issue lookup | **Escape** | Close the suggestions without choosing one. |
| **Explore / Test case / Verify fix** choices | Any arrow key | Select and focus the previous or next session type, wrapping at the ends. |
| Result choices | Any arrow key | Select and focus the previous or next available result, wrapping at the ends. |
| Additional MIME type field | **Enter** | Add the typed value to the capture-rule list. |
| Open MIME type list | **Escape** | Close the list and return focus to its button. |
| Send-menu arrow | **Up Arrow** or **Down Arrow** | Open the destination menu and focus an item. |
| Send destination menu | **Up Arrow** or **Down Arrow** | Move through destinations, wrapping at either end. |
| Send destination menu | **Home** or **End** | Move to the first or last destination. |
| Send destination menu | **Escape** | Close the menu and return focus to its arrow. |
| Send destination menu | **Tab** | Close the menu and continue through the page. |

Session-type, result, stopped-session lookup, and send-destination controls depend on the selected session type and project.

## Move around the session viewer

### Tabs, search, and history

| Focus | Keys | Result |
| --- | --- | --- |
| Viewer tab row | **Left Arrow** or **Right Arrow** | Open the previous or next viewer tab, wrapping at either end. |
| Viewer tab row | **Home** or **End** | Open the first or last viewer tab. |
| Viewer content, outside an input or button | **/** | Focus the current view's search field when it has one. |
| Evidence list, outside an open disclosure | **Escape** | Clear that view's active filters. An open menu or popup handles Escape first instead. |
| Viewer content, outside a text field | **Alt+Left Arrow** or **Alt+Right Arrow** | Move backward or forward through evidence you opened inside the viewer. On macOS, the Alt key is labelled Option. |
| Divider between an evidence list and its detail | **Left Arrow** or **Right Arrow** | Make the list pane narrower or wider in 24-pixel steps. |

The history shortcut does not run while focus is in an input, text area, select control, or editable region, so it does not interfere with editing.

### Evidence lists

| Focus | Keys | Result |
| --- | --- | --- |
| Network or Timeline row | **Up Arrow** or **Down Arrow** | Focus and open the adjacent row. The list stops at its first and last row. |
| Console row | **Up Arrow** or **Down Arrow** | Focus and open the adjacent row. |
| Console row | **Enter** or **Space** | Open the row's detail. |
| Request or log nested under an action | **Enter** or **Space** | Open that related evidence beside the action. |
| Annotatable action, request, log, or field | **Right-click**, or **Control-click** on macOS | Open the field actions. Choose **Pin** to mark the evidence without a comment, or **Note** to write one. If you selected part of a value first, Recorder uses that selection as the note excerpt. |
| Annotatable evidence field | **Shift+F10** or the **Context Menu** key | Open the same **Pin**, **Note**, and available privacy actions without using a pointer. |
| Open field-action panel | **Escape** | Close it and return focus to the field. |

Buttons and button-like rows elsewhere in Actions, Screenshots & Attachments, Notes, Tests, and Overview use **Enter** or **Space**. On a narrow window, activating a row also opens its detail pane; arrowing through a list only changes the selected row.

On macOS, use **Control-click**, not Command-click, for the contextual field actions. Command-click is not assigned to Pin or Note.

## Edit session content

| Focus | Keys | Result |
| --- | --- | --- |
| Title | **Enter** | Save the edited title and leave the field. |
| Title | **Escape** | Restore the current saved title and leave the field. |
| Action-name editor | **Escape** | Cancel the rename and return focus to **Rename**. |
| Delete-action confirmation | **Escape** | Cancel deletion and return focus to **Delete**. |
| Description editor | **Tab** | Indent the current line or selected lines. |
| Description editor | **Shift+Tab** | Remove one indentation level from the current line or selected lines. |
| Description editor | **Escape**, then **Tab** | Let the next Tab leave the editor. Typing another non-modifier key restores Tab indentation. |
| **Add** or **Improve** menu button | **Down Arrow** | Open the menu and focus its first item. |
| Open Description menu | **Up Arrow** or **Down Arrow** | Move through items, wrapping at either end. |
| Open Description menu | **Home** or **End** | Move to the first or last item. |
| Open Description menu | **Escape** | Close the menu and return focus to its button. |
| Open Description menu | **Tab** | Close the menu and continue through the page. |

## Privacy preview

| Focus | Keys | Result |
| --- | --- | --- |
| Source or record row | **Enter** or **Space** | Open that source or record. |
| Privacy search | **Escape** | Clear the search text when it is not empty. |
| Expanded original-value control | **Escape** | Collapse the original value. |

**Enter** and **Space** open the same record that a pointer click opens; the keys do not change whether a value is hidden or visible in the export.

## Keyboard actions in the application under test

Recorder does not reserve the application's shortcuts. During recording it captures **Enter**, **Escape**, and **Tab**; shortcuts that combine another key with **Control**, **Meta** (such as Command on macOS), or **Alt/Option**; supported slider keys; and supported arrow-key movement in tabs, menus, list boxes, and similar widgets. It can also capture an unmodified printable shortcut when the page handles it outside a text-entry or sensitive field.

A held key is recorded once rather than once per repeat. Recorder does not record a modifier pressed by itself as a meaningful action. When reviewing keyboard evidence, turn **Key actions only** off in Actions because that filter hides keydown events.

For the full Viewer workflow, see [Open the session viewer](https://fairleadhq.com/docs/recorder/session-viewer/). For captured-key limits and protected values, see [Capture support and limits](https://fairleadhq.com/docs/recorder/developers/capture-support/) and [How redaction works](https://fairleadhq.com/docs/recorder/redaction-rules/).

---

# Investigate slow or unresponsive behavior
Canonical: https://fairleadhq.com/docs/recorder/slow-or-unresponsive/
Markdown: https://fairleadhq.com/docs/recorder/slow-or-unresponsive.md

A recommended blueprint for tracing a delayed interaction through requests, timings, logs, and screenshots.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Choose the workflow mode, trace action-to-request-to-visible timing, preserve the measurement source, and hand off a scoped responsiveness finding.

## Prerequisites

- Recorder installed; affected interaction identified

## Inputs

- Expected responsiveness and test conditions

## Outputs

- A delay observation with diagnostic evidence

## Limitations

- Recorder is not a benchmark tool; the initiating action can leave the retained timeline

## Permissions

- Authorization to test the application

## Privacy

- Review evidence before sharing

This is a **recommended blueprint for investigating a slow or unresponsive interaction with Recorder**. Adapt it to the delay you can observe: a request that takes a long time, a spinner that remains after a response, or a click with no visible result. The aim is to preserve the initiating action and enough timing, screen, and error evidence to guide the next investigation.

Use it with [bug reproduction](https://fairleadhq.com/docs/recorder/bug-reproduction/) or [test execution](https://fairleadhq.com/docs/recorder/test-execution/) when the check is already defined.

## Choose the mode and follow this 10-step path

- Select **Explore** for an open-ended delay investigation or new performance report.
- Select **Test case** when a case states the response or completion criterion; enter its case ID and later choose Passed, Failed, or Blocked.
- Select **Verify fix** for a known performance issue on a candidate build; choose the issue and later choose Fixed or Not fixed.

1. Record the build, data size, cache/login state, device/network conditions, expected behavior, and measurement method in **Description**.
2. Select **Start recording** and perform the affected action once.
3. Capture the waiting state and, when it arrives, the completed state.
4. Select **Stop → Investigate** before the initiating action leaves the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
5. Confirm the initiating action and input.
6. Locate the relevant request or local/page work and inspect its start, end, duration, response, and dependencies.
7. Compare completion time with the screenshot or manually measured visible result.
8. Add comments that identify every measurement's source and avoid causal overstatement.
9. Choose the supported mode result, or leave it unselected when evidence is blocked/inconclusive and the mode has no matching result.
10. Finish Description, review/download/send, verify the handoff, then use **New recording**.

| Measurement | What it means | What it does not prove |
| --- | --- | --- |
| Request Timing | Captured interval/phases for one request | Total user-visible wait or responsible backend function |
| Manual wait | Time measured with the method you state | Which request or page task caused it |
| Environment connection | Browser-reported connection estimate | Throughput of the recorded request |
| Timeline long task | Recorded main-thread interval near the symptom | Causality without further comparison |
| Screenshot | Visible state at its timestamp | Exact duration by itself |

## Prepare a comparable attempt

Open the application and Recorder's side panel. Select local recording or the connected project, and prepare the affected data. Note the application build, dataset size, cache/login state, and any network/device conditions you deliberately changed. Recorder's **Environment** tab supplies some browser and page context, not these application-specific preconditions.

Use a title such as `Search delay - A1 - warm cache`. A found issue can prefill an unchanged Title and offer its description; add it only when it helps this attempt. Changing one condition for A2 should produce a separate result you can compare.

## Capture the start of the delay

1. Select **Start recording** and wait for the active state.
2. Perform the affected action once. Repeated clicks can create extra requests or change the problem; include them only if that is the behavior you need to reproduce.
3. Use **Capture** for the visible viewport while the spinner, unchanged screen, or error is present. Use **Area** when a region is enough, keeping the submitted value and result area in view.
4. If the result arrives within the useful capture period, take another image of the completed state. Note how you measured the user-visible wait, if you measured it separately.
5. Select **Stop**, then **Investigate** before the initiating action leaves the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).

For a longer unresolved wait, stop with the beginning and waiting state preserved rather than silently losing the initiating action. Write `Still waiting at Stop` and the observed duration. Stopping freezes the recording; a response arriving later will not update that stopped evidence. A later screenshot or another recording can show a later state, but identify it as later evidence and state the gap.

## Locate the delay in the sequence

Separate three moments: **the action begins, the relevant request completes, and the expected state becomes visible**. Recorder can provide request timings and captured states; screenshots alone do not measure the exact duration of the user's wait.

### Establish the input and request interval

1. In **Actions → Recorded Actions**, select the initiating search, save, or navigation. Inspect **Target**, available **Captured value**, **What changed**, and **Element & form state**. Confirm the intended action/input occurred and whether the page was already busy, disabled, or showing invalid fields.
2. Expand the action's request count and select the operation's request. In **Payload**, confirm the actual query/record so you do not time unrelated background traffic. Use **Open in Network tab** to inspect retries or dependent requests. Open Network directly if nothing is associated.
3. Open **Timing**. Pin the useful start, end, duration, or phase by right-clicking the field → **Pin**. Keep the units and source. A missing phase is unknown, not zero; linked **Browser performance timing** is a separate measurement source from the request timing.
4. Open **Response**. Was the required result returned, an application error reported, or the body unavailable? Check the failure summary and **Headers** when cancellation, blocking, redirects or a recorded cache source could explain the wait. A 200 header does not guarantee that the response body completed successfully.
5. Open **Timeline** and inspect the waiting/completion image relative to these events. A request row is at its start time: use the Timing end before saying the spinner outlasted it. Select the screenshot to inspect the actual state at that time.

For example, a waiting-state screenshot captured after the relevant response ended supports “the wait continued after this request.” It does not prove the request was the final dependency, nor that the page was frozen throughout the interval.

### Follow the branch supported by the evidence

| Observation | Where to look next and why | Useful finding to save |
| --- | --- | --- |
| No matching request is captured | Check broader **Network**, action/form state, page reaction and relevant **Console** details. The operation may be local, blocked before sending, or outside capture scope. | What input/state was captured and whether a relevant request could be found; leave the missing link explicit |
| A relevant request is long or unfinished at Stop | Inspect **Timing**, status/failure summary and available response. Check whether the image falls within that interval. | Recorded duration or unfinished state, plus the visible wait; a wait phase does not identify a backend handler |
| Several requests retry or wait on one another | Read the **Session network waterfall**, then inspect each request's input, result and end time. | The sequence that prolongs the operation; do not add overlapping durations as if they were sequential |
| The required response completes but the spinner remains | Look for later requests/stream updates, relevant exceptions and page reaction; inspect nearby Timeline long tasks. | Correct/incorrect response plus the later visible wait and any supporting diagnostic event |
| The page changes but the user cannot interact normally | Inspect **Timeline** long-task duration/attribution and **Console** stack context. | An interval worth profiling; proximity does not prove the task caused the symptom |
| The display depends on a live update | Open captured **EventStream** or WebSocket messages and compare their time/data with the display. | Whether the relevant update was observed; preserve safe WebSocket excerpts manually because local downloads omit frames |

Click a relevant **Console** entry to inspect Message, Stack trace, source and arguments. Pin the exact useful detail, not every error. Use **Initiator** on a request for available script-origin context a developer can follow. **Cause** returns to a likely associated action, which still needs checking against your input and timeline.

### Separate interaction timing from starting conditions

Open **Environment** to compare browser, viewport/zoom and connection context across attempts. Its **Document load** describes the document open when capture started and may predate the interaction. Its connection tier is a browser estimate, not a measurement of this request's throughput.

In **Timeline**, open available long-task, paint or resource events for their recorded detail. Some buffered measurements can predate Start. Standalone performance/lifecycle entries do not have their own note editor; copy a useful event's time, duration and source into the initiating action's note or Description. A linked resource measurement may instead be available and annotatable under request **Timing**.

### Save the timing argument

Open **Notes**, select each useful pin and **View evidence**. Use **Add comment** to connect measurement and observation: `This request ended at [time], but image [reference] at [later time] still shows the spinner. Check later dependencies and page work; the recording does not identify the responsible function.` Mark the deciding evidence **Important**, then **Save comment**.

Add a separate note to each waiting/completion image in **Screenshots & Attachments**. Label a still-waiting-at-Stop result explicitly. If the recording cannot locate the delay, preserve that gap and choose one next capture or profiling question. If you already have a clear interval and relevant evidence, hand it off before expanding into unrelated performance measurements.

## Save the conditions with the observation

Open **Notes**, remove irrelevant pins, and use **Add comment** on the useful ones. **View evidence** should lead to the exact timing field, log entry, or image. Keep the measurement source in the text so a recipient can distinguish a request duration from a manually measured UI wait.

In **Description → Split**, adapt this record:

```markdown
Interaction / attempt: search / A1
Build / environment / role: [fill in]
Input / dataset / cache state: [fill in]
Expected: [expected response or agreed timing criterion]
Observed: [result appeared, error, or still waiting at Stop]
User-visible wait: [duration and measurement method, or not measured]
Relevant request: [method/path and recorded duration, or unavailable]
Evidence: [NOTES]
Capture gap: [late response, missing body, or other limit]
Comparison: [other attempt reference and changed condition, if any]
```

Select `[NOTES]` and choose **Add → Notes** to insert saved comments/pins. Read **Preview** and resolve any save error. Use **Undo** for an insertion in the wrong place. If you revise a source note, update its inserted copy too. Label estimates as estimates instead of giving them the appearance of measured timings.

## Preserve comparisons and hand off

Review **Privacy preview**, authored text, console details, and image pixels. Select **Download report** and check completion in Chrome. Open `session.md`, available `notes.md`, `network.har`, and the relevant PNGs. Copy important viewer-only measurements into Description because the folder does not recreate every diagnostic panel.

Attach reviewed evidence through the [bug-report workflow](https://fairleadhq.com/docs/recorder/bug-reporting/) and check the recipient can open it. Before **New recording**, add the folder reference to your comparison notes. Use `A2` for a changed cache state, dataset, or build, keeping all other known conditions the same where practical. Describe the difference in its title/notes rather than merging the attempts into one unexplained average.

Use a browser profiler for detailed main-thread analysis or repeatable benchmarks. Recorder's [performance evidence](https://fairleadhq.com/docs/recorder/environment-and-performance/) is partial: it does not calculate INP or CLS or provide throttling presets. The [shared workflow guide](https://fairleadhq.com/docs/recorder/testing-workflows/) covers partial downloads and other handoff recovery.

---

# Recorded actions and user steps
Canonical: https://fairleadhq.com/docs/recorder/steps-and-events/
Markdown: https://fairleadhq.com/docs/recorder/steps-and-events.md

Read actions and inspect the evidence around them.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Inspect individual recorded actions and generate user steps. Both generation modes send the report to the project Data Plane; action associations do not prove causation.

## Prerequisites

- A recorded session open in the viewer

## Inputs

- Retained actions and related evidence

## Outputs

- An interpreted action sequence

## Limitations

- Generated steps need review; action associations do not prove causation

## Permissions

- Access to the session

## Privacy

- Review the report before generating user steps; both modes send it to the project Data Plane

Use **Recorded Actions** to understand a retained sequence, then **Event Log** to inspect the underlying action detail.

## Read the steps

[Open the viewer](https://fairleadhq.com/docs/recorder/session-viewer/), select **Actions**, then **Recorded Actions**. Begin with the starting page, then compare the narrated actions with the check you performed.

Recorded Actions lists individual recorded actions in sequence. It is not a complete transcript of every physical input. The starting-page row provides context for the retained interval.

## Inspect an action

Select an action to inspect its target, label, selectors, and available related evidence. Accessible names and roles help identify controls; selector alternatives help developers review generated tests.

A label can be missing or ambiguous. Compare the target with the application before treating a generated locator as reliable. Redacted or unavailable values do not mean a field was empty.

## Filter, rename, or remove an action

Search for a target or use **Key actions only**, **Has evidence**, or **Needs attention** to focus the list. **Group by page** helps follow page transitions. These filters change the view, not the report or downloads.

Open an action and use **Rename** to make its narrative clearer. This does not change the captured input or generated test commands. **Delete** asks for permanent confirmation and removes the action from the report and exports; it cannot be undone. Actions linked to requests or logs cannot be deleted. Preserve the original evidence before removing anything you may need.

## Read the event log

Use **Event Log** when you need individual recorded events and timing. Compare it with Recorded Actions to inspect navigation or state changes around an interaction.

Review available URL changes and DOM/state changes in action details. These are diagnostic observations, not a complete DOM replay or a screenshot of every state.

## Generate user steps

To generate reproduction instructions, you need to be signed in with a configured project Data Plane and **Save recorded data in Data Plane** enabled. This feature is separate from the locally displayed Recorded Actions.

1. Review the report and its [data destination](https://fairleadhq.com/docs/recorder/privacy/).
2. Open **Description**. For a current local recording, the same editor is used whether or not an issue is selected.
3. Open **Add** and choose **Steps to reproduce** for deterministic generation or **Steps written by AI**.
4. Review the inserted text against the evidence, correct it, and check that your edits saved. Use **Undo** to reverse an insertion.

Both modes contact the project's Data Plane. **Steps to reproduce** sends a reduced report with actions and metadata, retaining request URLs, status, timing, and identifiers but removing network headers, bodies, cookies, stream messages, logs, performance events, attachments, and annotations. **Steps written by AI** sends the full report. Review authored metadata as well as captured values before either operation.

For a local alternative, choose **Add → Recorded actions**. This inserts the starting page and action sequence without contacting a service. **Add → Notes** inserts saved observations. These insertions use the full retained sequence regardless of Actions filters and are available without an account. The description editor and its insertion menu are not available in stored-session review.

## Follow related evidence

Open related requests or console entries from an action to investigate the result. A timing-based association suggests where to look; it does not prove that the action caused the request or error.

Add a [note](https://fairleadhq.com/docs/recorder/notes/) to an action to state what was expected and what you observed.

## Explain gaps

The [retained-timeline limit](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) determines which actions remain at Stop. Earlier actions may be absent, and frame or component boundaries can limit target details. Describe missing steps in your execution record. Use [navigation and frame guidance](https://fairleadhq.com/docs/recorder/navigation-and-frames/) when the gap occurs across pages or embedded content.

---

# Open a stored session
Canonical: https://fairleadhq.com/docs/recorder/stored-sessions/
Markdown: https://fairleadhq.com/docs/recorder/stored-sessions.md

Review project evidence from Control Plane.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Review project evidence from Control Plane. Stored review has no local attachment editing or test generation; expired handoffs must be reopened.

## Prerequisites

- Recorder installed; signed-in access to the project

## Inputs

- A stored session opened from Control Plane

## Outputs

- Read-only report review

## Limitations

- Stored review has no local attachment editing or test generation; expired handoffs must be reopened

## Permissions

- Access to the stored session and its project

## Privacy

- Review content and destination before sharing

Open a stored session from Control Plane to inspect the report in Recorder's viewer. You need Recorder installed, a signed-in account, and access to the relevant project.

## Open the report

1. Open the project in Control Plane.
2. Find the session in its sessions view.
3. Use the session's open action to launch Recorder.

Recorder opens or focuses the matching viewer and retrieves the stored report using a short-lived authorization handoff.

## Review the evidence

Use the available action, network, console, and environment views as you would for local review. Keep the tester's expected and actual result alongside the evidence.

Stored-session review cannot save annotation changes. **Add note**, **Edit comment**, and **Save comment** can still appear, but saving a note fails. Keep new observations separately. This view does not provide local screenshot attachments, generated-test downloads, or the local bundle download workflow. The stored viewer is not a way to resume recording.

The local **Description** editor and its action, note, and generated-step insertion menu are unavailable here. Keep a separate account of any new interpretation and refer to the stored evidence.

## Reopen an expired session

If the viewer says the link has expired, return to Control Plane and open the session again. Reloading the old tab cannot reuse its one-time handoff.

Projects configured with a **private** Data Plane cannot open stored sessions through this viewer. For other retrieval failures, confirm your sign-in, project access, and the configured report destination. Ask the project administrator to investigate persistent retrieval failures.

## Share through the project

Use the project's approved sharing process and check that recipients have access. Do not copy an extension-local viewer URL into a TMS and assume it gives another person access. [TMS evidence](https://fairleadhq.com/docs/recorder/tms-evidence/) covers manual files and accessible links.

Resetting your local recording does not delete a stored project report. Its retention is controlled by the destination.

---

# Execute a test case
Canonical: https://fairleadhq.com/docs/recorder/test-execution/
Markdown: https://fairleadhq.com/docs/recorder/test-execution.md

Run one identifiable manual test attempt, choose a supported result, and attach evidence another person can verify.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use Test case, map expected results to evidence, choose Passed, Failed, or Blocked, and complete the manual TMS handoff.

## Prerequisites

- Recorder installed; an authoritative test case, environment, and safe data

## Inputs

- Test-case ID, expected results, run reference, and attempt conditions

## Outputs

- A Passed, Failed, or Blocked recording with checked evidence

## Limitations

- TMS search and result synchronization are unavailable; early steps can leave the retained interval

## Permissions

- Authorization to test the application and update the external test run

## Privacy

- Review captured and authored evidence before downloading or sending

Use this workflow for one planned manual case or one named checkpoint of a longer case. Select **Test case** so Recorder stores the case reference and offers **Passed**, **Failed**, or **Blocked** after Stop. Recorder does not fetch the case or update its run in a test-management system (TMS).

> **Example references:** lane and badge examples use the [Quackban sample](https://fairleadhq.com/docs/recorder/testing-workflows/#shared-example-quackban). Apply the decisions to your own case criteria.

## Follow this 10-step path

1. Select **Test case** and enter the authoritative case ID, such as `TC-142`.
2. Add a recognizable Title and write the run, build, role, safe data, covered steps, and expected results in **Description**.
3. Select **Start recording** and execute the case at its intended pace.
4. Capture every decisive visible result with its subject and surrounding context.
5. Select **Stop → Investigate** before the relevant checkpoint leaves the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
6. For each criterion, confirm the intended action, relevant data, and visible state; retain positive evidence for a pass as well as discrepancies for a failure.
7. Add source comments naming the case step, expected result, observation, and evidence limit.
8. Choose **Passed**, **Failed**, or **Blocked** only after every required criterion's status is known.
9. Finish Description and use **Add → Notes** to insert the reviewed evidence.
10. Review privacy, download or send, enter the result in the TMS manually, verify the attachment, then use **New recording**.

## Know who supplies each part

| Part | Recorder | Tester | Destination |
| --- | --- | --- | --- |
| Test-case ID | Stores the typed value; does not search a TMS | Enter the exact authoritative ID | Report metadata and Description context |
| Case content | Does not import steps or expectations | Keep the source case open and name covered steps | Remains authoritative in the TMS |
| Browser evidence | Captures supported actions, requests, logs, timing, and images | Decide which sources establish each criterion | Viewer, report, and local files |
| Result | Offers Passed, Failed, Blocked after Stop | Choose from checked criteria, not error counts | Report and supported send text |
| Issue | Offers create/no-issue for Failed or Blocked when a tracker is configured | Decide whether the result warrants a defect | Issue tracker; independent of the TMS result |
| TMS result | Shows the destination as unavailable | Enter result, step, and attachments manually | External TMS |

The Test case field is presented as required, but Start does not enforce it. If you omit it, the report cannot identify the authoritative case. Correct the field before handoff rather than relying on the Title.

## Prepare an identifiable attempt

For a short case, use one recording per attempt. For a longer case, choose checkpoints that fit the retained interval, such as `C1 — create card` and `C2 — move card`. Keep their order and uncovered gaps in the external run.

Use a Title such as `TC-142 - A1 - pending - Move card`. In Description, record the run and attempt, covered steps and expected results, application build and role, safe data reference, pre-Start setup, and conditions Recorder cannot infer from Environment.

## Match each criterion to evidence

Treat every expected result as a small chain: **intended action → affected subject → returned or visible state**.

1. In **Actions → Recorded Actions**, open the relevant step and inspect **Target**, captured value, form state, page changes, and URL changes.
2. Open its request count when the criterion depends on data. Check Payload and Response or the next read for the same subject.
3. Open the checkpoint image. Verify enough context to judge the criterion.
4. Use Timeline and request Timing when the image might precede completion or a later update might change the result.
5. For keyboard checks, turn **Key actions only** off. For missing traffic, search Network directly.

Pin supporting evidence, then add a Notes comment using `Step → expected → observed → limit`.

## Choose the result

| Result | Use it when | Include |
| --- | --- | --- |
| **Passed** | Every required criterion was checked and met | Positive evidence for decisive checks |
| **Failed** | An executed criterion did not meet its expectation | First failed step, expected/actual, and unexecuted steps |
| **Blocked** | A missing prerequisite prevented the required check | Blocker, last reached step, and what remains untested |

Do not choose Passed because Overview is clean, requests return 200, or the action sequence completed. If evidence is inconclusive, say so in Description and repeat or hand off manually; Recorder has no Inconclusive result choice.

## Write, deliver, or recover

```markdown
Test case: TC-142 — Move card between lanes
Run / attempt / checkpoint: release-42 / A1 / C1
Build / environment / role: [fill in]
Data: [safe reference]
Result: Failed
Expected: [criterion]
Observed: [specific result]
Remaining steps: [not executed / completed]
Evidence: [NOTES]
Bug: [issue ID or triage pending]
```

Insert Notes, review Preview, and resolve any Description save error. Open Privacy preview, select **Download report**, and inspect the actual files.

Enter the result and failed/blocked step in the TMS manually. Failed or Blocked can create an issue or keep **No issue**; Passed has no issue action. **Send data to Fairlead** stores the report only. The locked TMS item does not mean anything was synchronized.

If evidence or a download is incomplete, retain the ready session and retry. Preserve a failed long-case recording before making a focused reproduction. Use A2 for a rerun, and select **New recording** only after the external run points to evidence that opens.

[Choose another testing workflow](https://fairleadhq.com/docs/recorder/testing-workflows/).

---

# Record test outcomes
Canonical: https://fairleadhq.com/docs/recorder/test-outcomes/
Markdown: https://fairleadhq.com/docs/recorder/test-outcomes.md

Record the result against the behavior you actually checked.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Choose Recorder's supported Test case or Verify fix result after assessing the evidence, and record other scoped outcomes in Description or the external system.

## Prerequisites

- Defined expectations and observations from a test

## Inputs

- Executed checks and evidence references

## Outputs

- A scoped result summary

## Limitations

- Outcomes are tester-assessed; skipped checks and missing evidence must remain explicit

## Permissions

- Access to your test notes or result system

## Privacy

- Review content and destination before sharing

Record your assessment alongside the evidence. Recorder never assigns a result automatically. After Stop, **Test case** offers Passed, Failed, or Blocked; **Verify fix** offers Fixed or Not fixed; **Explore** has no result control.

## Compare expected and actual behavior

Start with the case's acceptance criteria or the exploratory charter. Identify which checks were executed on which build and environment. Describe the observation before deciding the result.

| Outcome | Use when |
| --- | --- |
| Passed | The defined expected results were checked and met |
| Failed | Observed behavior did not meet a defined expectation |
| Blocked | A prerequisite prevented execution |
| Incomplete | An interruption stopped the attempt before a final result; state the last completed step |
| Inconclusive | Execution or evidence did not support a reliable decision |

Use your team's equivalent statuses where needed. Keep skipped checks separate from passed ones.

## Write a result summary

Write the check, conditions, expected and actual result, outcome, and evidence references in **Description** or your TMS. Identify missing context explicitly instead of guessing it. For the [real sample](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle):

```text
Check: Clear the Blocked badge when a card leaves Blocked
Application / data: Quackban, Pond Redesign, QB-DEMO sticky Blocked
Execution: 2026-10-07, 04:43:24.309 UTC; 42 seconds
Expected: In progress card has no Blocked badge
Actual: Status changes to in_progress; cropped image still shows the badge
Outcome: Failed against the tester's stated expectation
Evidence: session.md action 20; network.har entries 4–5; screenshots/003-area.png
Unknown: Application build and TMS run reference were not supplied
Scope: This capture checks In progress; Done/reload remarks concern earlier runs
```

These assessment details belong in Description even when you also choose a Recorder result. The selector stores the supported result; it does not explain criteria, gaps, or unexecuted checks. Downloaded `session.md` carries Description and `notes.md` carries saved annotations when present.

For an exploratory check, use scoped wording such as “No issue observed while testing empty and single-item baskets on this build.” For a reproduction attempt, “not reproduced” describes that attempt and does not prove a fix.

## Link the evidence

Reference the relevant [downloaded files](https://fairleadhq.com/docs/recorder/bundle-contents/) and the action or request that supports the result. For long cases, identify checkpoint order and any unrecorded intervals. A bounded [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) cannot prove every step of a longer execution.

Blocked and Inconclusive remain useful written outcomes outside the selector where the chosen mode does not offer them. Never choose Not fixed merely to send an inconclusive verification. See [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes), and record the result in your TMS separately.

---

# Testing workflows
Canonical: https://fairleadhq.com/docs/recorder/testing-workflows/
Markdown: https://fairleadhq.com/docs/recorder/testing-workflows.md

Choose Explore, Test case, or Verify fix, then capture, investigate, and preserve a result another person can verify.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Choose the Recorder session type for a QA job, understand its lookup and result controls, and follow the shared capture-to-handoff routine.

## Prerequisites

- Recorder installed and authorization to test the application

## Inputs

- A question, test case, reported issue, or fix to verify

## Outputs

- A reviewed recording with an explicit result or next question

## Limitations

- TMS lookup and result synchronization are not available; evidence retention is bounded

## Permissions

- Authorization to test the application and any selected destination

## Privacy

- Review captured and authored data before downloading or sending

Choose the job before you record. Recorder uses that choice to label the lookup field, preserve the session's purpose, offer the supported result choices after Stop, and decide which destinations are available. It does not decide whether the application behaved correctly.

## Choose the session type

| Your job | Select | Lookup | Result after Stop | Start with |
| --- | --- | --- | --- | --- |
| Explore a question or report a newly found problem | **Explore** | Optional issue; leave empty for a new issue | No Recorder result control | [Capture an exploratory discovery](https://fairleadhq.com/docs/recorder/exploratory-testing/) or [report a bug](https://fairleadhq.com/docs/recorder/bug-reporting/) |
| Execute a planned check | **Test case** | Type the test-case ID; TMS search is not available | **Passed**, **Failed**, or **Blocked** | [Execute a test case](https://fairleadhq.com/docs/recorder/test-execution/) |
| Check a candidate fix | **Verify fix** | Select the issue being verified | **Fixed** or **Not fixed** | [Verify a fix](https://fairleadhq.com/docs/recorder/fix-verification/) |

Use [Reproduce a reported bug](https://fairleadhq.com/docs/recorder/bug-reproduction/) for a focused attempt against an existing report. The specialist blueprints cover [smoke or regression batches](https://fairleadhq.com/docs/recorder/regression-testing/), [accessibility evidence](https://fairleadhq.com/docs/recorder/accessibility-evidence/), and [slow interactions](https://fairleadhq.com/docs/recorder/slow-or-unresponsive/).

## Follow the shared 10-step path

1. **Choose the job.** Select **Explore**, **Test case**, or **Verify fix**. Do not use a convenient result label for a different job.
2. **Identify the subject.** Enter the issue or test-case reference. For Test case, a typed ID is saved with the report but is not looked up in a TMS.
3. **Write the criterion.** In **Description**, record the build, starting state, expected result, and observation that will decide the outcome.
4. **Capture the relevant path.** Select **Start recording**, perform the check, capture the visible result with enough context, then select **Stop** before decisive evidence leaves the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
5. **Open the evidence.** Select **Investigate**. Begin at the known action or symptom, not with an obligatory tour of every tab.
6. **Follow one subject.** Compare the intended action, sent data, returned state, later updates, and visible result. Preserve identity and time when moving between views.
7. **Explain the evidence.** Pin useful leads, then use **Notes → View evidence → Add comment → Save comment** to state what each source establishes and what remains uncertain.
8. **Choose the supported result.** Use the result control only when the selected session type offers one and the required criterion was actually checked.
9. **Write the account.** In **Description**, put the outcome or observation first, followed by conditions, expected/actual behavior, evidence, gaps, and the next useful check.
10. **Preserve and verify.** Review **Privacy preview**, download or send the result, open the destination/files, and only then select **New recording**.

## Understand what Recorder fills and what you supply

| Part | Recorder does | You do | Save or destination |
| --- | --- | --- | --- |
| Session type | Stores Explore, Test case, or Verify fix with the report | Choose the job that matches the attempt | Persists with the recording |
| Issue lookup | Searches a configured tracker for Explore or Verify fix | Select a result or type a key; verify the issue is correct | Found issue metadata stays with the recording |
| Test-case lookup | Stores the typed ID; shows TMS search as unavailable | Enter the authoritative case ID | Included with the report; no TMS is updated |
| Title | Can fill an unchanged Title from a found issue | Keep it or edit it intentionally | Saves with session details; can be sent to the tracker |
| Issue description | Offers **Add** when a found issue has text | Decide whether to append it; review earlier appended text | Appends to Description and never stays synchronized |
| Description | Provides one Markdown editor in the local Viewer | Write the attempt account and insert reviewed Notes/actions | Autosaves after a pause or blur; no submission occurs yet |
| Source comments | Keeps each note attached to an action, field, request, log, or image | Explain why the source changes the conclusion | Requires **Save comment**; exported to `notes.md` when present |
| Result | Shows choices for Test case and Verify fix after Stop | Choose only the supported outcome | Stored in the report and included in supported sends |
| Send menu | Shows currently configured and locked destinations | Choose the tracker action, Fairlead storage, or manual handoff | Nothing leaves the browser until the selected action is run |

A found issue's description is never copied automatically. **Add** appends it to Description; **Not now** leaves your text unchanged. If you later choose another issue, review any text already appended from the first one.

## Investigate a result, not a tab list

Use the expected result to decide what evidence matters:

1. In **Actions → Recorded Actions**, confirm the intended control and subject. Read **Target**, captured values, form state, page changes, and URL changes where relevant.
2. Open associated requests. Check **Payload** for the subject and intended change; check **Response** or a following read for the resulting state. HTTP 200 alone does not establish a pass.
3. Open the result image. Confirm that it shows the claimed subject and context. Use **Timeline** and request **Timing** when completion order matters.
4. Follow Console, live messages, Environment, or performance evidence only when it can distinguish the remaining explanations.

Stop when you can state the supported result or observation, the evidence behind it, the important gap, and the next useful check. A clean Overview, absent error, or generated script is not a verdict.

## Write and deliver the result

Use Description for the account of this recording. Older stored reports can contain a separate legacy reproduction-notes value; the current local editor does not edit that legacy field.

```markdown
Job / reference / attempt: [fill in]
Build / environment / role: [fill in]
Expected: [criterion]
Observed: [specific result]
Recorder result: [when the selected type provides one]
Evidence: [insert reviewed Notes]
Capture gaps / next check: [fill in]
```

Select the evidence placeholder and choose **Add → Notes**. This inserts a copy of saved comments and bare pins. Finish comments first; later edits to source notes do not update the inserted text. Description autosaves after a pause or blur. Resolve any save error before handoff.

The send choices depend on the session:

- Explore without an issue can create one; Explore with an issue can update it or replace its description.
- A Failed or Blocked Test case can create an issue or keep **No issue**. Passed results have no issue action. TMS delivery remains locked and must be completed in the TMS manually.
- Verify fix can **Add evidence only** after an issue and Fixed/Not fixed result are chosen. Automatic issue transitions are not available; change status in the tracker yourself.
- **Send data to Fairlead**, when available, stores the report without sending anything to the tracker or a TMS.
- **Download report** supports a local/manual handoff for every ready recording.

Open the actual destination after sending. Issue mutation, screenshot attachment, report storage, download completion, and later TMS attachment can succeed or fail independently. Retry only the failed part; after an unknown tracker timeout, check the tracker before submitting again.

## Shared example: Quackban

The workflow guides use a synthetic Quackban case to demonstrate investigation decisions. The reported problem is: a card enters Blocked, moves to In progress, but keeps its Blocked badge. Expected: leaving Blocked clears the badge. The sample follows one card across the action, move request, following board read, and final image.

[Download the sample bundle](https://fairleadhq.com/downloads/fairlead-recorder-sample-v1.zip), unzip it, and open `session.md` and `notes.md`. The archive also contains `network.har`, scripts, recorded steps, and screenshots. See the [sample bundle reference](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle) or the [worked reproduction](https://fairleadhq.com/docs/recorder/bug-reproduction/#worked-example-read-the-supplied-bundle).

---

# Attach execution evidence to a TMS
Canonical: https://fairleadhq.com/docs/recorder/tms-evidence/
Markdown: https://fairleadhq.com/docs/recorder/tms-evidence.md

Associate reviewed evidence with the correct case and run.

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use Test case to preserve an ID and result with the report, then attach reviewed evidence and enter the result in the TMS manually.

## Prerequisites

- Access to the relevant TMS case and run

## Inputs

- Reviewed files or approved accessible links

## Outputs

- Evidence mapped to the execution result

## Limitations

- Manual handoff only; no native TMS connector or automatic verdict synchronization

## Permissions

- Permission to update the case or run and share its evidence

## Privacy

- Review content and destination before sharing

Select **Test case** and type the authoritative case ID before recording. Recorder stores that ID and offers Passed, Failed, or Blocked after Stop, but TMS lookup and delivery remain locked **Soon**. Attach evidence and enter the result through your TMS manually.

## Identify the execution

Open the correct case and run. Record the build, environment, browser, tester, execution time, and relevant test-data reference. Use the TMS's result fields for your assessment.

## Prepare the handoff

1. [Review the recording](https://fairleadhq.com/docs/recorder/review-redaction/) and download the files you need.
2. Map each folder or file to its case step or checkpoint.
3. Write expected and actual behavior, the outcome, and any skipped checks.
4. Attach the selected files using the TMS's attachment controls.

See [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes). Attach `session.md` and available `notes.md`, and enter the assessment in the TMS result fields.

## Example evidence set

For the [real sample](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle), attach `session.md`, `notes.md`, `network.har`, and the relevant PNGs to your own case/run. Describe the failed expectation: leaving Blocked should clear the badge. Reference action 20 and HAR entries 4–5 for the last move, and explain that `003-area.png` has no lane heading. The supplied recording contains no TMS run reference; do not invent one or claim it was synchronized.

## Use links when appropriate

Use an approved stored-session link only if the intended reviewers can open it. Check project access and any extension or sign-in requirements. An extension-local viewer URL is not a shareable evidence link.

For files, confirm the TMS accepts the format and size. Open an attachment after uploading to ensure it is usable by the intended recipients.

## Explain multiple recordings

List checkpoint recordings in execution order. State where capture started and stopped, including gaps between segments. The [retained-timeline limit](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) still applies; several files do not automatically prove continuous execution of the entire case.

## Record the result

Use [Record test outcomes](https://fairleadhq.com/docs/recorder/test-outcomes/) to distinguish passed, failed, blocked, and inconclusive. Link a defect if needed, but keep the execution result on the case/run. An attachment failure should be reported as a handoff problem, not silently treated as a complete evidence record.

---

# Sign-in, uploads, and issue submission
Canonical: https://fairleadhq.com/docs/recorder/troubleshooting-connections/
Markdown: https://fairleadhq.com/docs/recorder/troubleshooting-connections.md

Resolve account and destination failures without duplicating work.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Resolve account and destination failures without duplicating work. A timeout can leave an issue command outcome unknown; check the tracker before retrying.

## Prerequisites

- A connected-project workflow and its error message

## Inputs

- The failing sign-in or submission operation

## Outputs

- A targeted recovery action without duplicate submission

## Limitations

- A timeout can leave an issue command outcome unknown; check the tracker before retrying

## Permissions

- Project access and authorization for the failing destination

## Privacy

- Review content and destination before sharing

Read the failing operation before retrying. Sign-in, tracker commands, attachments, and report storage have separate outcomes.

## No project profile is available

Ask your Fairlead administrator to assign a project profile to your account. Signing in successfully does not establish project access or configure a destination.

## Sign-in expired or a token failed

Use **Connect via browser** again. For a one-time connection token, obtain a new token if it expired or was already used. Browser restart can require reconnecting. Confirm the selected project afterward.

## Tracker credentials are missing

Follow Recorder's Control Plane link to connect the personal account required by the project. For Azure DevOps, the link may open the project's Issue Tracker page for the selected organisation. Reconnect expired or revoked authorization there.

Do not paste provider tokens into Recorder.

## The destination is not configured

A missing tracker route or Data Plane endpoint is an administrator configuration issue. Ask your administrator to check the selected project and destination. Personal sign-in alone cannot repair it.

If report storage is disabled by project policy, upload and enhancement remain unavailable even when the tracker works.

## A version compatibility error appears

An unsupported protocol error means the extension and Bridge service cannot complete that operation together. Update Recorder through your normal Chrome update process or ask your administrator to align the service. Repeating the same command will not fix the mismatch.

## Submission timed out

A timeout, including a 504 response, can mean the issue command's outcome is unknown. Check the tracker for the issue or update before retrying. Keep the time and project reference for investigation.

## Only part of the submission succeeded

Preserve the successful issue reference. Retry a failed screenshot attachment independently when offered, and resolve storage failure separately. Report upload failure does not undo issue creation. For description conflicts, review the append/replace choice in [Create or update an issue](https://fairleadhq.com/docs/recorder/issue-trackers/).

---

# Downloads and generated tests
Canonical: https://fairleadhq.com/docs/recorder/troubleshooting-exports/
Markdown: https://fairleadhq.com/docs/recorder/troubleshooting-exports.md

Resolve incomplete downloads and scripts that need adaptation.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Resolve incomplete downloads and scripts that need adaptation. Keep the local session while retrying; files depend on available evidence.

## Prerequisites

- A stopped local session or its downloaded artifacts

## Inputs

- A failed download or generated-script symptom

## Outputs

- A recovered download or identified script adaptation

## Limitations

- Keep the local session while retrying; files depend on available evidence

## Permissions

- Local download access; authorization for any replay environment

## Privacy

- Review content and destination before sharing

Keep the stopped session available while investigating an export problem. Selecting **New recording** clears local evidence you may still need.

## Some files did not download

Retry **Download** in the viewer, or **Download report** in the account-free side panel, after checking Chrome's download status and available storage. A partial failure leaves the session intact. Inspect the resulting folder to confirm the files completed; a started download may still be interrupted.

## An expected file is missing

Compare the folder with [Download session artifacts](https://fairleadhq.com/docs/recorder/bundle-contents/). Screenshot files require added attachments. Recorder writes a folder; the website's real sample was packaged as a ZIP for sharing.

`notes.md` requires saved annotations or pins. `console.log` is omitted when no console text is generated. `session.md` is the written summary, not `session.txt`. Check the actual folder even when the summary links to a file: the real sample links to an absent console log. Retry a reported download failure before resetting.

WebSocket frames and all viewer diagnostics are not part of the standard bundle.

## A request or input value is redacted

Review the export before running it. Supply safe credentials and test values in your test project; do not weaken recording privacy rules to recover a secret. Missing bodies cannot be reconstructed by the exporter.

## A generated script fails

Check the starting URL, authentication, data, installed framework, and target environment. A generated navigation does not recreate an authenticated session.

Review locators for ambiguous or dynamic targets. Add condition-based waits, setup and cleanup, and assertions. Unsupported actions may need manual implementation. Refer to [reliable automated tests](https://fairleadhq.com/docs/recorder/developers/reliable-automated-tests/).

## The Tests view is unavailable

A failure to load generated artifacts can affect **Tests** while the rest of the local report remains readable. Preserve other evidence and retry the local workflow if necessary. Stored-session review does not offer local test generation; open a local recorded session for that workflow.

---

# Recording and missing evidence
Canonical: https://fairleadhq.com/docs/recorder/troubleshooting/
Markdown: https://fairleadhq.com/docs/recorder/troubleshooting.md

Find the cause of a failed capture or an incomplete recording.

Updated: 2026-10-07
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Find the cause of a failed capture or an incomplete recording. Evicted events and unavailable bodies cannot be recovered from the stopped session.

## Prerequisites

- Recorder installed; the capture symptom available

## Inputs

- A start error or missing evidence

## Outputs

- A diagnostic next step

## Limitations

- Evicted events and unavailable bodies cannot be recovered from the stopped session

## Permissions

- Website access and browser debugging for capture

## Privacy

- Review diagnostic content before sharing

Start with whether capture began, which page was in scope, and whether the evidence falls inside the retained interval.

## Recording does not start

Use an ordinary application page. Chrome internal URLs, extension pages, and other protected surfaces cannot be recorded. Account-free recording also excludes local file URLs.

If Recorder is waiting for navigation, open an allowed application page or select **Stop recording** to cancel. For a connected project, confirm its domain and destination requirements and the selected issue state.

## Browser debugging cannot attach

Read the error shown in the panel. Organisation policies or another debugging connection can prevent attachment. Another extension's embedded frame can also block recording on a page.

If the message identifies an extension conflict, try an approved clean browser profile or disable the conflicting extension for the test, then reload the page. Do not remove required organisation controls; ask your administrator when policy blocks access.

## Earlier actions are missing

Compare the missing action with the [retained-timeline limit](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention). The elapsed timer does not mean that the whole recording remains available.

Record a shorter checkpoint if needed. Save each segment before **New recording** and note the gaps in the execution summary.

## Requests from another domain are missing

Check page and network scope. Local recording uses the starting hostname family; connected projects use their [capture configuration](https://fairleadhq.com/docs/recorder/capture-configuration/). Clear viewer filters before concluding capture omitted the request.

## Iframe values or targets are incomplete

Check iframe trust rules, frame provenance, and component boundaries. Untrusted values may be masked, and closed Shadow DOM can limit target details. Missing values do not prove a field was empty.

## Response bodies are unavailable or truncated

Check payload limits, content filtering, browser availability, and whether the response was streaming or binary. The viewer cannot recover a body the capture did not retain.

## Capture stops unexpectedly

If the debugger disconnects or the recording tab closes, inspect whatever stopped evidence remains and preserve it before resetting. Record the interruption and avoid presenting the session as a complete check.

For other symptoms, use [downloads and generated tests](https://fairleadhq.com/docs/recorder/troubleshooting-exports/) or [sign-in and submission troubleshooting](https://fairleadhq.com/docs/recorder/troubleshooting-connections/).

---

# Acceptable Use Policy

Canonical: https://fairleadhq.com/legal/aup/

Updated: 2026-10-01
Publication state: published
Product version: platform

Agent summary: Acceptable Use Policy for the Fairlead platform, operated by Allyx, Inc. What is and is not permitted when using the Fairlead platform.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


What is and is not permitted when using the Fairlead platform.

This Acceptable Use Policy ("**AUP**") governs your use of the Fairlead platform and services provided by Allyx, Inc. ("**Allyx**"), including any related applications, agents, APIs, integrations, and documentation (collectively, the "**Service**"). This AUP is incorporated by reference into the Allyx Terms of Service or other agreement governing your use of the Service (the "**Terms**"). Capitalized terms not defined in this AUP have the meanings given in the Terms. In this AUP, "**you**" means the Customer and includes its Authorized Users and any other person accessing or using the Service through the Customer's account or credentials. Allyx may update this AUP in accordance with the modification and notice provisions of the Terms. Unless a shorter period is required by law or reasonably necessary to address security, abuse, or operational risks, Allyx will provide at least thirty (30) days' notice of material changes to this AUP.

## 1. Authorized Use

You may use the Service only:

- in accordance with the Terms, any applicable Order Form, the Documentation, and this AUP;
- for systems, applications, repositories, environments, source code, data, and accounts that you own, control, or are expressly authorized to access and test; and
- in compliance with applicable laws and regulations.

The restrictions in this AUP do not prohibit the intended use of the Service's documented testing, instrumentation, code-analysis, automation, and integration functionality against systems, repositories, and environments that you are authorized to access and test.

## 2. Prohibited Uses

### 2.1 Illegal, Harmful, or Infringing Activities

You must not use the Service to:

- violate any applicable local, state, national, or international law or regulation;
- facilitate fraud, identity theft, phishing, deception, impersonation, or unauthorized access to another person's systems, accounts, or data;
- transmit, store, or process content that is unlawful, fraudulent, threatening, abusive, defamatory, or that infringes or misappropriates another person's intellectual property, privacy, confidentiality, or other legal rights; or
- export, re-export, access, or use the Service in violation of applicable export-control, trade-restriction, or economic-sanctions laws.

### 2.2 Unauthorized Systems, Code, and Credentials

Because the Service may instrument applications, access source code, execute tests, and interact with connected environments, you must use it only against authorized targets. You must not:

- instrument, test, scan, access, or direct the Service at any application, system, endpoint, environment, repository, source code, or account that you do not own, control, or have express authorization to access and test;
- use the Service to probe, scan, penetration-test, attack, overload, disrupt, or gain unauthorized access to any third-party system;
- use the Service as a vector for a denial-of-service attack or any similar disruptive activity;
- provide the Service with source code, data, credentials, API keys, access tokens, or other materials that you are not authorized to provide or use;
- misrepresent the scope of your authorization to access, test, instrument, or modify any system, repository, environment, or source code; or
- use the Service to circumvent or defeat an access control, authentication mechanism, rate limit, bot or anti-automation protection, CAPTCHA, or similar safeguard on any system that you do not own or are not authorized to test.

You are responsible for obtaining and maintaining all permissions required for the systems, environments, code, credentials, and integrations you connect to the Service.

### 2.3 Security and Service Integrity

You must not:

- attempt to gain unauthorized access to the Service, Allyx's infrastructure, another customer's account or data, or any related system or network;
- probe, scan, or test the vulnerability of the Service or any Allyx system without Allyx's prior written authorization;
- knowingly introduce, transmit, execute, or store malware, ransomware, viruses, Trojan horses, worms, destructive code, or other technology intended to compromise, damage, or disrupt the Service or any third party;
- circumvent, disable, compromise, or interfere with any security, authentication, authorization, or access-control feature of the Service;
- interfere with or disrupt the integrity, performance, operation, or availability of the Service or Allyx's infrastructure;
- exceed documented API rate limits or impose an unreasonable or disproportionate load on the Service;
- use the Service for cryptocurrency mining or other compute-intensive activity unrelated to the documented purpose of the Service; or
- circumvent, manipulate, disable, or interfere with usage metering, billing measurement, subscription limits, storage limits, or other technical restrictions applicable to the Service.

### 2.4 Data Protection and Restricted Data

You must not:

- submit or make available through the Service any personal data for which you do not have all rights, permissions, notices, consents, and legal bases required under applicable data protection law;
- use the Service to violate another person's privacy or confidentiality rights;
- use production personal data in a test environment unless necessary for authorized testing, permitted by applicable law, and protected by appropriate safeguards (data minimization, masking, de-identification, encryption, access controls); or
- use the Service to process personal data concerning children where such processing is prohibited by applicable law or is not expressly permitted by the applicable Order Form and Documentation.

**"Restricted Data"** means:

- protected health information regulated under HIPAA or similar health-privacy laws;
- payment-card account data, including full payment-card numbers and sensitive authentication data;
- bank-account credentials or other credentials that permit access to a financial account;
- government-issued identification numbers;
- biometric or genetic data used to identify a person;
- special-category personal data or personal data concerning criminal convictions or offenses;
- personal data concerning children where additional legal authorization or safeguards are required; and
- any other information subject to industry-specific or regulatory requirements that the Service is not expressly designed or documented to support.

You must not submit Restricted Data to the Service unless the applicable processing is expressly permitted by the Documentation, an Order Form, and any additional agreement required by Allyx. Passwords, private keys, API keys, access tokens, and other secrets required for an authorized integration may be provided only through the Service's designated credential-management functionality. You must not intentionally place such secrets in source code, prompts, logs, issue descriptions, test data, or other free-form fields submitted to the Service.

### 2.5 High-Risk Uses

You must not use the Service in connection with a system where the failure, fault, error, or output of the Service could reasonably be expected to directly cause death, serious bodily injury, or substantial physical or environmental damage. Prohibited uses include use in connection with:

- medical devices or clinical systems where errors could directly affect patient safety;
- aircraft, aviation, navigation, or human mass-transportation control systems;
- nuclear, chemical, or critical energy-infrastructure control systems;
- weapons targeting, launch, or control systems; or
- autonomous vehicle control software used in a production environment.

You must not rely on the Service as the sole testing, validation, approval, or safety-control mechanism for any safety-critical system.

### 2.6 Unauthorized Commercial and Competitive Use

Except as expressly permitted under the Terms or an applicable Order Form, you must not:

- resell, sublicense, distribute, rent, lease, provide, or otherwise make the Service available to a third party;
- use non-public features, interfaces, technical information, or Allyx Confidential Information to replicate the Service or develop a substantially similar competing commercial service;
- publicly disclose, publish, or distribute benchmark tests, comparative performance results, or competitive analyses concerning the Service without Allyx's prior written consent; or
- frame or mirror the Service on another website, application, or platform.

This Section does not restrict your use of Service Output to the extent permitted under the Terms.

### 2.7 Reverse Engineering and Unauthorized Automated Access

Except to the extent expressly permitted by applicable law, you must not:

- reverse engineer, decompile, disassemble, decode, or otherwise attempt to derive the source code, underlying structure, models, methods, or algorithms of the Service;
- access the Service through interfaces, credentials, methods, or means other than those provided or authorized by Allyx;
- use bots, scrapers, crawlers, or other automated means to extract data or content from the Service, except through an API, agent, CLI, SDK, integration, or other automated method provided or expressly authorized by Allyx; or
- copy, modify, or create derivative works of any portion of the Service except as expressly permitted under the Terms.

### 2.8 Misrepresentation

You must not:

- impersonate Allyx, an Allyx employee, another customer, or any other person or entity in connection with the Service;
- misrepresent your identity, organization, affiliation, authority, or permissions to obtain access to the Service or any connected system or data; or
- use false, misleading, stolen, or unauthorized account or payment information in connection with the Service.

## 3. Responsibility for Accounts and Users

You are responsible for:

- ensuring that your Authorized Users comply with this AUP;
- safeguarding your account credentials and integration credentials;
- configuring and using the Service in accordance with the Documentation and your legal, security, and compliance obligations; and
- activity conducted through your account, credentials, environments, and integrations, except to the extent that unauthorized activity results from Allyx's breach of its obligations under the Terms.

You must promptly notify Allyx if you become aware of: compromised account or integration credentials; unauthorized access to or use of the Service; a material violation of this AUP; or activity involving the Service that presents a material legal, security, privacy, or operational risk.

## 4. Monitoring and Enforcement

Allyx may investigate suspected violations of this AUP. If Allyx reasonably determines that a violation has occurred, Allyx may:

- request that you stop or remediate the prohibited activity;
- issue a warning or impose reasonable use restrictions;
- remove, disable, isolate, or quarantine content, code, tests, configurations, credentials, or integrations that Allyx reasonably believes violate this AUP or present a security or operational risk;
- restrict or suspend access to affected functionality or to the Service where reasonably necessary to protect the Service, Allyx, another customer, or a third party;
- terminate your account or subscription in accordance with the Terms; or
- preserve or disclose relevant information, or report suspected unlawful activity, to law-enforcement agencies, regulators, or other appropriate authorities as permitted or required by applicable law.

Allyx may take immediate action without prior notice where reasonably necessary to address an urgent security, legal, privacy, or operational risk. For non-urgent violations, Allyx will use reasonable efforts to provide notice and an opportunity to address the violation before suspending or terminating the Service.

## 5. Reporting Violations

If you become aware of activity involving the Service that may violate this AUP, please report it promptly to: security@fairleadhq.com. Please include sufficient information to help Allyx investigate and address the reported activity.

## 6. Relationship to the Terms

This AUP is incorporated into and governed by the Terms. If this AUP conflicts with the Terms, the Terms control unless this AUP expressly states otherwise. A violation of this AUP constitutes a violation of the Terms and may result in restriction, suspension, or termination of access to the Service as provided in the Terms.

---

fairleadhq.com/legal/aup

© 2026 Allyx, Inc. All rights reserved.

---

# Cookie Policy

Canonical: https://fairleadhq.com/legal/cookies/

Updated: 2026-10-01
Publication state: published
Product version: platform

Agent summary: Cookie Policy for the Fairlead platform, operated by Allyx, Inc. How the Fairlead platform uses cookies and similar technologies.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


How the Fairlead platform uses cookies and similar technologies.

Allyx, Inc. ("**Allyx**," "**we**," "**us**," or "**our**") operates the website at fairleadhq.com (the "**Website**"). This Cookie Policy explains what cookies and similar technologies we use on the Website, why we use them, and the choices available to you.

## 1. What Are Cookies

Cookies are small text files placed on your device when you visit a website. They let a website recognize your browser on later visits and support functionality, security, and analytics.

In addition to cookies, we use browser local storage (not sent to our servers, and not a cookie) for two purposes:

- **Appearance preference:** remembers your choice of light or dark mode.
- **Cookie preference:** remembers whether you accepted or declined analytics cookies in the banner described in Section 3, so we don't ask you again on every visit.

These preferences are not sent to Google Analytics or shared as identifiers. Cookie choices are stored under `fl_cookie_consent` until you change them or clear site data. If browser storage is unavailable, a choice applies to the current page and may be requested again on navigation.

## 2. Cookies We Use

### 2.1 Strictly Necessary Cookies

The Website itself has no login, user accounts, or authenticated area, so we do not set any strictly necessary cookies through our own code (for example, session or CSRF cookies). If that changes — for instance, if we launch a customer portal — we will update this policy before doing so.

Our hosting and security provider, **Cloudflare, Inc.**, may set cookies directly from its network as part of keeping the Website secure and available, independent of our own code — for example:

| Cookie | Set by | Purpose | Typical duration |
|---|---|---|---|
| `cf_clearance` | Cloudflare | Records that a visitor has passed a Cloudflare security check, so they aren't re-challenged on every request | Depends on Cloudflare's challenge/security configuration |
| `__cf_bm` | Cloudflare | Helps Cloudflare distinguish legitimate visitors from automated bot traffic | 30 minutes |

Cloudflare may set additional cookies depending on which of its security and performance features are active at a given time; these are outside Allyx's direct control. Cloudflare describes its own privacy practices — including that this data may be processed in the United States — at cloudflare.com/privacypolicy. Cloudflare classifies all of these as strictly necessary.

### 2.2 Analytics Cookies

We use **Google Analytics** (Google LLC) to understand how visitors use the Website, such as which pages are viewed and where traffic comes from. Google Analytics sets first-party cookies on the fairleadhq.com domain:

| Cookie | Set by | Purpose | Typical duration |
|---|---|---|---|
| `_ga` | Google Analytics | Distinguishes unique visitors | Up to 2 years |
| `_ga_*` | Google Analytics | Persists session state for the Website's Analytics property | Up to 2 years |

If you are visiting from the European Economic Area, the United Kingdom, or Switzerland, these cookies are only set after you accept them in the cookie banner described in Section 3 — Google Analytics does not load until you do. Elsewhere, analytics loads by default unless you have declined it. Cookie Settings is available to every visitor. When we cannot determine whether consent is required, analytics waits for your choice.

Analytics can process online identifiers and device and usage information; we use its reports to understand aggregate website usage. We do not combine Google Analytics data with advertising networks. See Google's privacy policy at policies.google.com/privacy and its cookie controls at policies.google.com/technologies/cookies for how Google handles this information.

**Local development:** Google Analytics is disabled on local development builds. Cookie Settings can still save a preference for that origin. Production analytics can also be disabled through site configuration. With JavaScript disabled, Google Analytics does not load. Cloudflare security cookies, where enabled, are independent of the analytics choice.

### 2.3 Marketing and Advertising Cookies

We do not use marketing, advertising, or cross-site tracking cookies on the Website, and we do not serve targeted advertising to visitors.

## 3. Your Choices

### 3.1 Cookie Banner (EEA, UK, and Switzerland)

If you visit the Website from the European Economic Area, the United Kingdom, or Switzerland, a cookie banner appears on your first visit, before any analytics cookies are set. You can:

- **Accept** — Google Analytics loads and sets the cookies described in Section 2.2.
- **Decline** — Google Analytics does not load, and no analytics cookies are set.

Your choice is remembered in your browser's local storage (see Section 1) so you aren't asked again on every visit. You can change your choice at any time using the **Cookie Settings** link in the Website's footer, which reopens the banner. If you had previously accepted and now decline, we disable further collection by this site’s Google Analytics tag and delete its accessible Google Analytics cookies. Your saved Decline choice prevents the tag from loading on later visits, in every region.

Visitors elsewhere can open the same banner through Cookie Settings to accept or decline analytics. Dismissing the banner without choosing does not grant consent.

### 3.2 Browser Controls and Opt-Out

Wherever you're visiting from, you can also control or block the Google Analytics cookies directly:

- **Browser controls:** Most browsers let you view, delete, or block cookies:
  - **Chrome:** Settings → Privacy and security → Cookies and other site data
  - **Firefox:** Settings → Privacy & Security → Cookies and Site Data
  - **Safari:** Preferences → Privacy → Manage Website Data
  - **Edge:** Settings → Cookies and site permissions → Cookies and site data
- **Google Analytics opt-out:** Install the Google Analytics Opt-out Browser Add-on at tools.google.com/dlpage/gaoptout to prevent Google Analytics from using your data across all websites.

Blocking cookies will not break any functionality of the Website, since it does not rely on cookies to operate.

## 4. Do Not Track and Global Privacy Control

Some browsers send a "Do Not Track" (DNT) signal or a Global Privacy Control (GPC) signal. Because there is no accepted standard for interpreting DNT, the Website does not currently respond to it. We do not sell or share personal information, so there is presently nothing for a GPC signal to opt out of; if that changes, we will honor a valid GPC signal where required by law.

## 5. Changes to This Cookie Policy

We may update this Cookie Policy from time to time to reflect changes in the cookies or technologies we use. We will revise the "Last Updated" date above when we do, and post material changes on this page.

## 6. Contact Us

If you have questions about this Cookie Policy, please contact us:

**Allyx, Inc.**\
1501 Yamato Rd, 2nd Floor #3030\
Boca Raton, FL 33431\
Email: legal@fairleadhq.com

---

# Data Processing Agreement

Canonical: https://fairleadhq.com/legal/dpa/

Updated: 2026-10-01
Publication state: published
Product version: platform

Agent summary: Data Processing Agreement for the Fairlead platform, operated by Allyx, Inc. Terms for processing personal data on behalf of Fairlead platform customers.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Terms for processing personal data on behalf of Fairlead platform customers.

This Data Processing Agreement ("**DPA**") is between Allyx, Inc., a Delaware corporation ("**Allyx**" or "**Processor**"), and the entity or individual identified as "Customer" in the applicable Terms of Service or Order Form ("**Customer**" or "**Controller**"). By accessing or using the Services, Customer agrees to be bound by this DPA.

This DPA is incorporated into and forms part of the Terms of Service between Allyx and Customer (the "**Agreement**"). Capitalized terms not defined in this DPA have the meanings given in the Agreement.

## Recitals

A. In the course of providing the Services, Allyx may process personal data on behalf of Customer as a data processor.

B. The parties wish to set out their respective rights and obligations with respect to such processing to comply with applicable data protection law, including the General Data Protection Regulation (EU) 2016/679 ("**GDPR**"), the UK General Data Protection Regulation ("**UK GDPR**"), and other applicable privacy laws.

C. The parties agree that this DPA shall supplement and prevail over the Agreement solely with respect to data protection matters.

## 1. Definitions

"**Applicable Data Protection Law**" means all laws and regulations applicable to the processing of Personal Data under this DPA, as amended from time to time, including the GDPR, UK GDPR, and any national implementing legislation.

"**Customer Personal Data**" means any Personal Data contained within Customer Data that Allyx processes on Customer's behalf in the course of providing the Services.

"**Data Subject**" means the identified or identifiable natural person to whom Personal Data relates.

"**Personal Data**" has the meaning given under Applicable Data Protection Law.

"**Processing**" has the meaning given under Applicable Data Protection Law, and "Process," "Processes," and "Processed" shall be construed accordingly.

"**Security Incident**" means any accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or unauthorized access to, Customer Personal Data.

"**Standard Contractual Clauses**" or "**SCCs**" means the standard contractual clauses for the transfer of personal data to third countries adopted by the European Commission under Decision 2021/914/EU, as may be amended or superseded by a competent authority.

"**Services**" means products, services, websites, and applications provided by Allyx, Inc., together with all associated features, and any updates, enhancements, or modifications thereto.

"**Sub-processor**" means any third-party processor engaged by Allyx to process Customer Personal Data.

## 2. Scope and Roles

### 2.1 Controller and Processor

Customer acts as the Controller of Customer Personal Data, and appoints Allyx to act as its Processor and, where applicable under the CCPA, as its Service Provider, with respect to Customer Personal Data processed in connection with the Services.

### 2.2 Description of Processing

This DPA applies to the Processing of Customer Personal Data by Allyx in connection with the provision of the Services. The details of the processing activities covered by this DPA are set out in Annex I to this DPA.

### 2.3 Instructions

Allyx shall process Customer Personal Data only on Customer's documented instructions and only as necessary to provide the Services, unless required to do so by applicable law. The Agreement, this DPA, any applicable Order Form, and any other written instructions agreed to by Allyx constitute Customer's documented instructions.

Customer may provide additional instructions in writing, subject to Allyx's right to charge for implementation costs. If Allyx is required by law to process Customer Personal Data for purposes other than Customer's instructions, Allyx shall notify Customer before such processing (unless prohibited by law).

If Allyx believes that a Customer instruction infringes Applicable Data Protection Law, Allyx shall promptly inform Customer.

### 2.4 Compliance with Law

Each party shall comply with its respective obligations under Applicable Data Protection Law. Customer is responsible for: (a) the lawfulness of its instructions to Allyx; (b) ensuring that Customer has a valid legal basis for processing Customer Personal Data; and (c) providing any required notices to Data Subjects.

Customer shall not, and shall ensure its Authorized Users do not, submit special categories of personal data (Article 9 GDPR) or other sensitive data to the Services except as expressly authorized in writing by Allyx under Section 3.5(c) of the Terms. Any such authorization forms part of Customer's documented processing instructions.

## 3. Security

### 3.1 Technical and Organizational Measures

Allyx shall implement and maintain appropriate technical and organizational security measures to protect Customer Personal Data against unauthorized or unlawful processing and against accidental loss, destruction, damage, or disclosure. As of the effective date, Allyx's security measures include those set out in Annex II to this DPA.

### 3.2 Confidentiality of Processing

Allyx shall ensure that persons authorized to process Customer Personal Data are subject to appropriate confidentiality obligations (whether by contract or under applicable law).

### 3.3 Updates to Security Measures

Allyx may update its security measures from time to time to reflect changes in technology and industry practice, provided that such updates do not materially diminish the overall security of Customer Personal Data.

## 4. Security Incidents

### 4.1 Notification

Allyx shall notify Customer without undue delay, and in any event within seventy-two (72) hours of Allyx confirming a Security Incident affecting Customer Personal Data. The notification shall include, to the extent known at the time:

(a) a description of the nature of the Security Incident, including the categories and approximate number of Data Subjects affected and the categories and approximate number of records affected;

(b) the name and contact details of Allyx's data protection contact;

(c) the likely consequences of the Security Incident; and

(d) the measures taken or proposed to be taken to address the Security Incident, including measures to mitigate its possible adverse effects.

Where it is not possible to provide all information within 72 hours, the initial notification shall contain the information then available, with further information provided promptly thereafter.

### 4.2 Cooperation

Allyx shall cooperate reasonably with Customer's investigation and mitigation of a Security Incident. Customer is solely responsible for making any notifications to supervisory authorities and Data Subjects that may be required under Applicable Data Protection Law.

## 5. Sub-processors

### 5.1 Authorization

Customer hereby provides general authorization to Allyx to engage Sub-processors, subject to the requirements of this Section 5.

### 5.2 Current Sub-processors

The Sub-processors currently authorized to process Customer Personal Data are listed in Annex III to this DPA and at [fairleadhq.com/legal/subprocessors](https://fairleadhq.com/legal/subprocessors/).

### 5.3 Changes to Sub-processors

Allyx shall give Customer at least thirty (30) days' prior written notice (which may be provided by email or by posting an update to [fairleadhq.com/legal/subprocessors](https://fairleadhq.com/legal/subprocessors/)) before engaging a new Sub-processor or making a material change to an existing Sub-processor.

If Customer reasonably objects to a new or changed Sub-processor on data protection grounds, Customer shall notify Allyx in writing within thirty (30) days of receiving notice. The parties shall negotiate in good faith to resolve the objection. If the objection is not resolved within a further thirty (30) days, Customer may terminate the Services by providing thirty (30) days' written notice to Allyx, and Allyx shall provide a pro-rata refund of any prepaid Fees covering the period after termination.

### 5.4 Sub-processor Obligations

Allyx shall impose on each Sub-processor data protection obligations that are no less protective of Customer Personal Data than those imposed on Allyx by this DPA. Where a Sub-processor processes Customer Personal Data outside the EEA, UK, or Switzerland, Allyx shall ensure an appropriate transfer mechanism (such as the Standard Contractual Clauses) is in place with that Sub-processor. Allyx remains responsible and liable to Customer for the acts and omissions of its Sub-processors (including onward transfers) to the same extent Allyx would be liable if performing the Sub-processor's services directly.

## 6. Data Subject Rights

Allyx shall provide Customer with reasonable technical assistance to enable Customer to respond to Data Subject requests to exercise rights under Applicable Data Protection Law (including rights of access, rectification, erasure, portability, restriction, and objection). If Allyx receives a request directly from a Data Subject purporting to relate to Customer Personal Data, Allyx shall promptly forward the request to Customer and shall not respond to the request except as instructed by Customer or required by law.

## 7. Data Protection Impact Assessments

To the extent required by Applicable Data Protection Law, Allyx shall provide Customer with reasonable assistance in conducting data protection impact assessments and, where required, in consulting with supervisory authorities, taking into account the nature of the processing and the information available to Allyx.

## 8. Data Deletion

### 8.1 Upon Termination

This DPA is terminated upon the termination or expiration of the Agreement. Unless required or permitted by applicable law, Allyx will delete all remaining copies of Customer Personal Data within sixty (60) days following termination or expiration of the Agreement.

### 8.2 Retention by Law

Notwithstanding Section 8.1, Allyx may retain Customer Personal Data to the extent required by applicable law, provided that Allyx continues to protect such data in accordance with this DPA and only processes it to the extent necessary for the required purpose.

## 9. Audit Rights

### 9.1 Information and Audit

Customer may, no more than once per calendar year (unless there is a reasonable cause related to a Security Incident or regulatory requirement), request information from Allyx to demonstrate compliance with this DPA by:

(a) requesting that Allyx complete a reasonable written questionnaire provided by Customer; or

(b) conducting an audit of Allyx's processing activities, upon at least thirty (30) days' prior written notice, at Customer's cost, during Allyx's normal business hours, and subject to reasonable confidentiality obligations.

Audits shall be conducted in a manner that minimizes disruption to Allyx's operations and shall not unreasonably access information belonging to other Allyx customers.

### 9.2 Certifications

Where Allyx holds relevant third-party security certifications or audit reports (such as a SOC 2 Type II report or ISO/IEC 27001 certificate), Allyx may satisfy Customer's audit request by providing such certifications or reports (or summaries thereof), subject to applicable confidentiality terms. As of the effective date, Allyx does not hold such certifications; until it does, Customer's audit rights are exercised under Section 9.1.

## 10. International Data Transfers

### 10.1 Transfers from EEA/UK to United States

Where Customer Personal Data is transferred from the EEA, UK, or Switzerland to the United States or another country not recognized as providing an adequate level of data protection, such transfers shall be governed by the Standard Contractual Clauses, which are incorporated into this DPA by reference as follows:

- **For EEA transfers:** Module Two (Controller to Processor) of the SCCs adopted by the European Commission under Decision 2021/914/EU, with Customer as "data exporter" and Allyx as "data importer."
- **For UK transfers:** The UK International Data Transfer Addendum to the EU SCCs (IDTA) as issued by the Information Commissioner's Office, incorporated by reference.
- **For Swiss transfers:** The Swiss Standard Contractual Clauses as applicable.

The details required by the SCCs (including processing purposes, categories of data, and technical measures) are set out in the Annexes to this DPA.

### 10.2 Supplementary Measures

Allyx shall implement and maintain supplementary measures as necessary to ensure that transfers of Customer Personal Data to Sub-processors comply with Applicable Data Protection Law.

### 10.3 Conflicts with SCCs

In the event of a conflict between this DPA and the SCCs incorporated under Section 10.1, the SCCs shall prevail solely to the extent necessary to resolve the conflict.

### 10.4 Data Privacy Framework

Where Allyx is certified under the EU-U.S. Data Privacy Framework (and, as applicable, the UK Extension and the Swiss-U.S. Data Privacy Framework), Allyx may rely on such certification as the transfer mechanism for the relevant transfers in lieu of the SCCs. As of the effective date, Allyx is not certified under the Data Privacy Framework and relies on the SCCs (Section 10.1); this Section 10.4 will apply if and when Allyx self-certifies.

## 11. Liability and Indemnification

Each party's liability under this DPA is subject to the limitations set forth in the Agreement. For the avoidance of doubt, claims arising under or in connection with this DPA — including claims arising from a Security Incident or a breach of data-protection obligations — are subject to the limitations of liability in the Agreement, including any exclusions and carve-outs in Section 10 of the Terms. Nothing in this DPA limits a party's liability to Data Subjects or supervisory authorities, or in respect of a party's obligations under Applicable Data Protection Law.

## 12. General

### 12.1 Precedence

In the event of a conflict between this DPA and the Agreement, this DPA shall prevail solely with respect to data protection matters.

### 12.2 Governing Law

This DPA shall be governed by the laws of the State of Delaware, without prejudice to the application of Applicable Data Protection Law and the exclusive jurisdiction of supervisory authorities and courts in the EEA or UK for GDPR/UK GDPR matters.

### 12.3 Amendment

Allyx may amend this DPA to reflect changes in Applicable Data Protection Law.

### 12.4 Severability

If any provision of this DPA is found to be invalid or unenforceable, the remaining provisions shall continue in full force and effect.

## 13. Government and Law-Enforcement Access Requests

### 13.1 Handling of Requests

If Allyx receives a legally binding request from a public authority, court, or law-enforcement body for disclosure of Customer Personal Data (a "**Government Access Request**"), Allyx shall, unless legally prohibited:

(a) promptly notify Customer of the request so that Customer may seek a protective order or other appropriate remedy;

(b) inform the requesting authority that Allyx is a processor acting on Customer's behalf and that the request should be directed to Customer where possible;

(c) review the legality of the request and challenge any request that Allyx considers to be unlawful, overbroad, or disproportionate, including by pursuing available avenues of appeal where there is a reasonable legal basis to do so; and

(d) disclose only the minimum amount of Customer Personal Data necessary to respond to the request.

### 13.2 Prohibition on Notice

If Allyx is legally prohibited from notifying Customer of a Government Access Request, Allyx shall use reasonable efforts to obtain a waiver of that prohibition and shall document its efforts so as to provide the information to Customer as soon as it is legally permitted to do so.

### 13.3 Records

Allyx shall maintain a record of Government Access Requests relating to Customer Personal Data and shall make summary information available to Customer on reasonable request, to the extent legally permitted.

## 14. US State Privacy Laws Addendum

### 14.1 Scope

This Section 14 applies to the extent Allyx processes Customer Personal Data that is subject to the California Consumer Privacy Act, as amended by the California Privacy Rights Act (collectively, "**CCPA**"), or to other applicable US state privacy laws (including, but not limited to, the Virginia VCDPA, Colorado CPA, Connecticut CTDPA, Utah UCPA, and Texas TDPSA) (together, "**US State Privacy Laws**"). Terms such as "Business," "Service Provider," "Contractor," "Controller," "Processor," "Sell," "Share," and "Process" have the meanings given in the applicable US State Privacy Law.

### 14.2 Roles

With respect to Customer Personal Data subject to the CCPA, Customer is the Business and Allyx is a Service Provider. Where other US State Privacy Laws apply, Customer is the Controller and Allyx is the Processor.

### 14.3 Service Provider / Processor Obligations

Allyx shall:

(a) process Customer Personal Data only for the limited and specified business purpose of providing the Services under the Agreement, and shall not retain, use, or disclose it for any other purpose, or outside the direct business relationship with Customer, except as permitted by US State Privacy Laws;

(b) not Sell and not Share Customer Personal Data (as "Sell" and "Share" are defined under the CCPA);

(c) not combine Customer Personal Data with personal information that Allyx receives from, or on behalf of, any other person, or collects from its own interaction with the data subject, except as permitted by the CCPA;

(d) comply with the applicable obligations of a Service Provider/Processor under US State Privacy Laws and provide the same level of privacy protection as required of a Business/Controller; and

(e) promptly notify Customer if Allyx determines that it can no longer meet its obligations under US State Privacy Laws.

### 14.4 Certification

Allyx certifies that it understands the restrictions set out in this Section 14 and will comply with them.

### 14.5 Assistance and Oversight

Allyx shall reasonably assist Customer in responding to verifiable consumer requests under US State Privacy Laws (consistent with Section 6) and grants Customer the right to take reasonable and appropriate steps to ensure that Allyx uses Customer Personal Data in a manner consistent with Customer's obligations under US State Privacy Laws.

### 14.6 Deidentified Data

If either party processes deidentified data, it shall maintain the information as deidentified, shall not attempt to reidentify it, and shall otherwise comply with the deidentified-data requirements of US State Privacy Laws.

## Annex I — Description of Processing

| | |
|---|---|
| **Subject matter of processing** | Operation of the Allyx products, services, websites, and applications, provided by Allyx, Inc., to deliver the Services |
| **Duration of processing** | For the duration of the Agreement, plus the deletion period under Section 8 |
| **Frequency of transfer** | Continuous, for the duration of the Agreement |
| **Retention period** | Customer Personal Data deleted within 60 days of termination (Section 8; Terms §3.7), except records required to be retained by law |
| **Nature of processing** | Any operations or set of operations which is performed on Personal Data, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure, or destruction. |
| **Purpose of processing** | Providing and supporting the Services |
| **Categories of personal data** | May include: identifiers of Customer engineers and end users (names, email addresses, user IDs); application data (form inputs, API responses, method arguments, database query parameters, network request, response payloads, etc) submitted through instrumented Customer applications during the sessions; browser session recordings (network headers, cookies, authentication tokens, console logs, user inputs) |
| **Special categories of personal data** | Not permitted unless expressly authorized in writing by Allyx (see Terms of Service, Section 3.5(c)) |
| **Categories of Data Subjects** | Customer engineers and other Authorized Users of Customer; end users of Customer's applications as captured from instrumented application |
| **Controller's contact for data protection** | As designated by Customer |
| **Processor's contact for data protection** | legal@fairleadhq.com |

## Annex II — Technical and Organizational Security Measures

As of the effective date of this DPA, Allyx implements and maintains the following technical and organizational measures, as applicable to the Services:

### Security Management

Allyx maintains technical and organizational safeguards designed to protect Customer Personal Data against unauthorized access, disclosure, alteration, loss, or destruction. Security controls are incorporated into the design, development, deployment, and operation of the Services.

### Access Control

Access to Customer Personal Data and production systems is restricted to authorized personnel with a legitimate business need and is granted according to the principle of least privilege.

Administrative access to production infrastructure is protected using multi-factor authentication (MFA), single sign-on (SSO), and role-based access controls, as applicable. Administrative and production system access and activity are logged to support security monitoring and investigation.

Personnel authorized to access Customer Personal Data are subject to confidentiality obligations.

### Data Segregation and Processing

Allyx logically segregates Customer Personal Data within its production systems and uses isolated processing environments for execution of customer-specific tasks.

Task execution environments are provisioned with isolated filesystems and are terminated following completion of the applicable task. Customer source code materialized within such environments is retained only for the period necessary to perform the applicable processing.

Customer data stored in shared platform services is separated using account- or tenant-specific access controls and storage boundaries.

### Encryption and Key Management

Customer Personal Data transmitted over public networks is protected using industry-standard encryption, including TLS 1.2 or higher.

Customer Personal Data is encrypted at rest using industry-standard encryption mechanisms. Sensitive credentials, access tokens, and platform secrets are additionally protected using managed encryption, key-management, and secrets-management services.

Allyx restricts access to cryptographic keys and secrets according to least-privilege principles.

### Network and Infrastructure Security

Allyx uses established cloud service providers to host and operate the Services. Such providers maintain physical, environmental, and infrastructure security controls and independent security assurance programs, including SOC 2 and ISO 27001 certifications, as applicable to their respective services.

Allyx uses network and perimeter security controls appropriate to the Services, including web application firewall (WAF) and distributed denial-of-service (DDoS) protections for public-facing endpoints.

Task execution environments are isolated from direct inbound public internet access. Service-to-service and infrastructure access is restricted according to operational requirements and least-privilege principles.

### Secure Development and Change Management

Allyx maintains secure software development and deployment practices designed to reduce the risk of introducing security vulnerabilities into production systems.

Changes to production software are subject to review prior to deployment. Allyx uses automated security checks as part of its software development process, including static application security testing, dependency vulnerability scanning, and secret detection.

Development and production access are controlled and restricted according to their respective operational purposes.

### Vulnerability Management and Security Monitoring

Allyx uses automated tools and operational processes to identify security vulnerabilities in application code, software dependencies, and production systems.

Identified vulnerabilities and security issues are evaluated and addressed based on their severity and associated risk.

Allyx monitors production infrastructure for security and operational events and maintains logs designed to support detection, investigation, and response to security incidents.

### Data Retention and Deletion

Allyx maintains data retention practices designed to limit retention of Customer Personal Data to periods necessary for providing the Services and satisfying applicable contractual or legal requirements.

Customer source code used in task execution environments is removed following completion of the applicable processing task. Other Customer Personal Data is retained and deleted in accordance with the Agreement, this DPA, and applicable retention settings.

Upon termination of the Services, Customer Personal Data may be exported and will be deleted in accordance with the deletion requirements set forth in this DPA, except where retention is required by applicable law.

### Business Continuity and Resilience

Allyx maintains technical measures designed to reduce the risk of service disruption and loss of Customer Personal Data.

Critical production data stores use redundancy and backup mechanisms appropriate to the applicable infrastructure and service.

Allyx uses backup and recovery mechanisms appropriate to the applicable production data store and also relies on the durability, redundancy, and recovery capabilities provided by its managed cloud infrastructure providers.

### Sub-processors and Third-Party Infrastructure

Allyx uses established cloud and technology service providers in connection with the processing of Customer Personal Data.

Allyx evaluates the security and data-protection practices of material service providers involved in processing Customer Personal Data and requires such providers to be subject to appropriate contractual data-protection obligations.

Physical security of third-party data centers is managed by the applicable cloud infrastructure providers in accordance with their respective security programs and independent certifications.

## Annex III — Authorized Sub-processors

The following Sub-processors are authorized to process Customer Personal Data as of the effective date of this DPA. The current list is maintained at [fairleadhq.com/legal/subprocessors](https://fairleadhq.com/legal/subprocessors/).

| Vendor | Location | Purpose |
|---|---|---|
| Google LLC | USA, EU | Infrastructure services; AI services; user analytics and marketing insights; identity provider for authentication |
| Axiom, Inc. | USA, EU | Observability and log management |
| Cloudflare, Inc. | USA, EU | A global edge platform, infrastructure services, AI services |
| GitHub | USA | Identity provider for authentication |
| Microsoft Corporation | USA | Identity provider for authentication |

The current, authoritative list (with vendor trust-center and sub-processor-list links) is published at [fairleadhq.com/legal/subprocessors](https://fairleadhq.com/legal/subprocessors/).

## Annex IV — Standard Contractual Clauses Reference

The SCCs incorporated by reference in Section 10.1 of this DPA are those adopted by the European Commission on 4 June 2021 under Decision 2021/914/EU (Module Two: Controller to Processor).

- **Clause 7 (Docking clause):** Not applicable.
- **Clause 9 (Use of sub-processors):** Option 2 (General written authorization) applies, with the notice period specified in Section 5.3 of this DPA.
- **Clause 11 (Redress):** The optional language is not included.
- **Clause 13 (Supervision):** The competent supervisory authority shall be determined based on the Customer's EEA establishment or habitual residence.
- **Clause 17 (Governing law):** The SCCs shall be governed by the law of the Member State in which the data exporter (Customer) is established.
- **Clause 18 (Choice of forum):** Disputes arising from the SCCs shall be subject to the courts of the Member State in which the data exporter (Customer) is established.

Annexes I, II, and III to the SCCs correspond to Annexes I, II, and III of this DPA respectively.

fairleadhq.com/legal/dpa

© 2026 Allyx, Inc. All rights reserved.

---

# Privacy Policy

Canonical: https://fairleadhq.com/legal/privacy/

Updated: 2026-10-01
Publication state: published
Product version: platform

Agent summary: Privacy Policy for the Fairlead platform, operated by Allyx, Inc. How Allyx handles personal data on the Fairlead platform.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


How Allyx handles personal data on the Fairlead platform.

Allyx, Inc. ("**Allyx**," "**we**," "**us**," or "**our**") is committed to protecting your privacy. This Privacy Policy explains how we collect, use, disclose, and protect personal information in connection with products, services, events, websites, and applications that link to this Policy (together, the "Allyx Services" or "Services").

Please read this policy carefully. By using our Services, you acknowledge that you have read and understood this Privacy Policy.

## 1. Two Types of Personal Data We Handle

This policy covers two distinct contexts in which Allyx handles personal data:

### 1.1 Account and Business Data (Allyx as Controller)

When you use our Services, create an account, communicate with our team, or enter into a commercial relationship with us, Allyx collects and processes personal data for which Allyx acts as the data controller. This data relates to our customers' representatives, Service visitors, and business contacts. This section of our Privacy Policy describes how we handle that data.

### 1.2 Customer Application Data (Allyx as Processor)

When our customers use the Services, their application data — including traces, logs, session recordings, and source code metadata — is processed through our platform. This data may contain personal data relating to end users of our customers' applications. When processing this data, Allyx acts as a data processor on behalf of the customer (the data controller), under the terms of the applicable Data Processing Agreement.

Allyx does not control, and is not responsible for, the privacy practices of its customers with respect to their end users. If you are an end user of a customer's application and have questions about how your data is handled, please contact that customer directly.

## 2. Personal Information We Collect

### 2.1 Information You Provide Directly

We collect information about you when you provide it to us directly.

- **Account information:** We collect information about you when you create an account with us, such as your name, email address, profile picture, company name, postal address, phone number, and payment information.
- **Support information:** We collect information you provide to us when you open a support request or otherwise communicate with us (such as through third-party websites). This may include your name, email address, title, company, and any other information you provide with your request.
- **General information:** We collect information you provide as a survey or feedback responses, requests the information, including name, email address, telephone number, IP address, and online identifiers.
- **Service information:** We collect personal information submitted to us when you are using our Services, including the information provided in logs, traces, and metrics. This information may include a name, email address, IP address, online identifiers, and mailing address.

### 2.2 Information We Collect Automatically

We automatically collect information about you when you access or use Allyx Services.

- **Your use of Allyx Services:** We collect information about how you use the Allyx Services, such as your session date, time, and duration; the pages you viewed and feature used; action was taken within the Service; and the page you visited before navigating to the Services.
- **Technical information:** We collect information about your computer or device when you access any of Allyx Services, such as the type of browser you use, your IP address, operating system, device identifiers, referring URL, and the location of your device.
- **Cookies and similar technologies:** As described in our Cookie Policy at [fairleadhq.com/legal/cookies](https://fairleadhq.com/legal/cookies/).

### 2.3 Information We Collect from Other Sources

We may also obtain information about you from other sources.

- **Other services are linked to your account.** We may collect information about you when you link your Allyx account with other services. For example, when you log in using a third-party identity provider (Google, GitHub, or Microsoft), we receive your name, email address, and profile picture from that provider, subject to your settings with that provider.
- **Through Allyx Services.** We may receive information about you from other users using Allyx Services.
- **Third parties.** We may receive information about you from third parties that provide business information to us or from public sources. This information may include things like your name, title, email address, phone number, and social media profile. We may combine this information with information we collect through other means described above.

### 2.4 Sensitive Personal Data

**Account and business data (controller role):** We do not intentionally collect special categories of personal data (Article 9 GDPR) or "sensitive personal information" (as defined under the CCPA/CPRA and other US state privacy laws) about our Services visitors or account holders, and we ask that you not provide it.

**Customer application data (processor role):** Because the Services ingests traces, logs, recorded sessions, and other technical data from customer environments, sensitive or special-category personal data may be present in the customer data that passes through the Services. Allyx does not solicit such data and processes it only as a processor on the customer's documented instructions. Customers are responsible for having a lawful basis to include such data and must not submit special-category data except as expressly authorized in writing (see our Terms of Service §3.5 and our Data Processing Agreement). Where we process sensitive personal information, we use it only to provide the Services and not for any other purpose.

### 2.5 Job Applicant Data

If you apply for a role at Allyx, we collect the information you provide (such as your name, contact details, CV/résumé, and employment history) and information from recruiting platforms or referrals. We use it solely to evaluate your application and run our recruitment process, on the basis of taking steps at your request prior to a potential employment contract and our legitimate interest in hiring. We retain applicant data for no longer than 24 months unless you consent to a longer period or we are required to retain it by law, and we do not use it for marketing.

## 3. How We Use Your Information

We use the personal data we collect for the following purposes and on the following legal bases:

| Purpose | Legal Basis (GDPR) | Legal Basis (CCPA) |
|---|---|---|
| Creating and managing your account | Performance of contract | Business purpose |
| Providing and supporting the Services | Performance of contract | Business purpose |
| Processing payments and sending invoices | Performance of contract | Business purpose |
| Communicating about your account, incidents, and services updates | Performance of contract / Legitimate interests | Business purpose |
| Responding to support requests | Performance of contract | Business purpose |
| Detecting and preventing fraud and security incidents | Legitimate interests | Business purpose |
| Analyzing aggregate usage to improve the Services | Legitimate interests | Business purpose |
| Sending marketing and product update emails | Consent (where required) / Legitimate interests | Business purpose (with opt-out) |
| Protecting the vital interests of a data subject (e.g., emergencies) | Vital interests | Business purpose |
| Complying with legal obligations | Legal obligation | Legal obligation |

Where we rely on legitimate interests, we have balanced those interests against your rights and freedoms; you may request information about that balancing assessment by contacting us.

## 4. How We Share Your Information

We do not sell your personal information. We share personal data only as described below.

### 4.1 Service Providers (Sub-processors)

We share personal data with third-party vendors who process it on our behalf to enable us to provide the Services and operate our business. These organizations, called "sub-processors", are identified below with their locations and the types of services they provide to Allyx.

| Vendor | Location | Purpose |
|---|---|---|
| Google LLC | USA, EU | Infrastructure services; AI services; user analytics and marketing insights; identity provider for authentication |
| Axiom, Inc. | USA, EU | Observability and log management |
| Cloudflare, Inc. | USA, EU | A global edge platform, infrastructure services, AI services |
| GitHub | USA | Identity provider for authentication |
| Microsoft Corporation | USA | Identity provider for authentication |

The vendors marked "Sub-processor" process Customer Data on our behalf and are listed as authorized sub-processors in our DPA.

We maintain a current sub-processor list at [fairleadhq.com/legal/subprocessors](https://fairleadhq.com/legal/subprocessors/). We will provide at least thirty (30) days' advance notice of material changes to our sub-processor list.

### 4.2 Business Transfers

If Allyx is acquired, merges with another company, or transfers all or a portion of its assets, personal data may be transferred as part of that transaction. We will notify affected users of any such transfer and any resulting material change to data handling.

### 4.3 Legal Requirements

We may disclose personal data if required to do so by law, regulation, court order, or governmental authority, or if we believe disclosure is necessary to protect the rights, property, or safety of Allyx, our customers, or the public. Where legally permitted, we will provide prior notice to affected users.

### 4.4 With Your Consent

We may share your information with third parties when you have explicitly consented to such sharing.

### 4.5 Aggregated and De-Identified Data

We may create and use aggregated or de-identified data that does not identify you. We maintain such data as de-identified, do not attempt to re-identify it, and use it only for purposes such as improving and securing the Services.

## 5. International Data Transfers

Allyx is incorporated in the United States, and our primary infrastructure is operated in the United States by Google Cloud Platform. If you are located in the European Economic Area (EEA), United Kingdom, or Switzerland, your personal data is transferred to the United States.

For transfers of personal data from the EEA, UK, or Switzerland to the United States, we rely on Standard Contractual Clauses (SCCs) approved by the European Commission (Commission Decision 2021/914), together with the UK International Data Transfer Addendum and the Swiss adaptations where applicable, as the legal basis for the transfer.

A copy of our SCCs is available upon written request to legal@fairleadhq.com.

**EU Representative (Article 27 GDPR):** Allyx is established in the United States and does not have an establishment in the EU/EEA. To the extent Article 27 of the GDPR requires it, Allyx will designate a representative in the EU/EEA for data protection matters and will publish that representative's name and contact details in this section upon appointment. Until an EU representative is appointed, EU/EEA data subjects may contact Allyx directly at legal@fairleadhq.com.

## 6. Data Retention

We only keep your personal information for as long as necessary to fulfill the purposes we collected it for, after which it will be deleted or archived unless we are required to keep it to comply with our legal obligations or for another legitimate and lawful purpose. To determine the appropriate retention period for personal information, we consider several factors, including:

- the terms of our agreements with you;
- our legitimate interests (as outlined in this Privacy Policy);
- our legal obligations;
- the amount and nature of your personal information.

In some cases, we may anonymize your personal information so that you are no longer identifiable, in which case we may use the resulting information without further notice to you.

## 7. Your Rights

Depending on your location, you may have the following rights regarding your personal data:

### 7.1 Rights Available to All Users

- **Access:** Request a copy of the personal data we hold about you.
- **Rectification:** Request correction of inaccurate or incomplete data.
- **Erasure:** Request deletion of your personal data, subject to legal retention obligations.
- **Portability:** Receive your personal data in a structured, machine-readable format.
- **Objection:** Object to processing based on legitimate interests.
- **Restriction:** Request that we limit our processing of your data in certain circumstances.
- **Withdraw consent:** Where processing is based on consent, withdraw it at any time (without affecting the lawfulness of prior processing).

### 7.2 Additional Rights Under GDPR (EEA and UK Users)

EEA and UK residents have the rights listed in Section 7.1 under the GDPR and UK GDPR. You also have the right to lodge a complaint with your local supervisory authority. A list of EU supervisory authorities is available at edpb.europa.eu.

### 7.3 Additional Rights Under US State Privacy Laws

Residents of California (CCPA, as amended by the CPRA) and of other US states with comprehensive privacy laws (including Virginia, Colorado, Connecticut, Utah, and Texas) have, depending on their state of residence, the following rights:

- **Know / Access:** the categories and specific pieces of personal information we collect, the sources, the business or commercial purposes, and the categories of third parties to whom we disclose it.
- **Delete:** request deletion of personal information we collected from you.
- **Correct:** request correction of inaccurate personal information.
- **Portability:** receive your personal information in a portable, machine-readable format.
- **Opt out of sale/sharing and targeted advertising:** Allyx does not sell or share personal information (as those terms are defined under the CCPA and other US state privacy laws), and does not process it for cross-context behavioral or targeted advertising.
- **Limit use of sensitive personal information:** to the extent we process sensitive personal information, we use it only as necessary to provide the Services and not for purposes that would trigger a right to limit under applicable law.
- **Opt out of profiling:** we do not engage in profiling that produces legal or similarly significant effects.
- **Non-discrimination:** we will not discriminate against you for exercising your rights, and we do not offer financial incentives in exchange for personal information.

**California "Shine the Light" (Civil Code § 1798.83):** We do not disclose personal information to third parties for their own direct-marketing purposes.

### 7.4 Exercising Your Rights

To exercise any of the rights described above, please contact us at:

- **Email:** legal@fairleadhq.com
- **Response time:** We will respond within thirty (30) days of receiving a verified request (or within 45 days if we notify you of an extension).

We may need to verify your identity before processing your request. We will not charge a fee for exercising your rights, unless your request is manifestly unfounded, excessive, or repetitive. Because Allyx operates exclusively online, we accept privacy requests by email at legal@fairleadhq.com.

### 7.5 Authorized Agents

You may use an authorized agent to submit a request on your behalf. We may require the agent to provide proof of your written authorization and may require you to verify your identity directly with us.

### 7.6 Appeals

If we decline to act on your request, you may appeal by emailing legal@fairleadhq.com with "Privacy Appeal" in the subject line. We will respond to your appeal within the period required by applicable law (for example, within 60 days under the Virginia VCDPA). If your appeal is denied, you may contact your state Attorney General or supervisory authority.

### 7.7 Opt-Out Preference Signals (Global Privacy Control)

Some browsers and extensions transmit opt-out preference signals such as the Global Privacy Control (GPC). Because Allyx does not sell or share personal information or use it for targeted advertising, there is currently no such processing to opt out of. If our practices change, we will treat a valid GPC signal as a request to opt out where required by law.

## 8. Marketing Communications

You can opt out of marketing emails at any time using the unsubscribe link in those emails or by contacting us. Even if you opt out of marketing, we will still send you service-related and transactional messages (such as billing, security, and account notices).

## 9. Cookies

We use cookies and similar tracking technologies to collect information about your interactions with Allyx Services. For detailed information about the cookies we use, their purpose, and how to control them, please see our Cookie Policy at [fairleadhq.com/legal/cookies](https://fairleadhq.com/legal/cookies/).

## 10. Children's Privacy

The Services are not directed to individuals under the age of 16 in the EU/EEA and UK, United States and other jurisdictions. We do not knowingly collect personal data from children under the applicable minimum age. If we become aware that we have collected personal data from such a child, we will take steps to delete such information promptly. If you believe we have inadvertently collected data from a minor, please contact us at legal@fairleadhq.com.

## 11. Security

We implement commercially reasonable administrative, technical, and physical security measures to protect your personal data from unauthorized access and against unlawful processing, accidental loss, destruction, and damage.

No security measure is perfect. In the event of a data breach that is likely to affect your rights and freedoms, we will notify you and, where required, the relevant supervisory authority, within the timeframes required by applicable law.

## 12. Third-Party Links

Our Services may contain links to third-party websites or services. We are not responsible for the privacy practices of those third parties. We encourage you to review the privacy policies of any third-party sites you visit.

## 13. Changes to This Privacy Policy

We may update this Privacy Policy from time to time. For material changes, we will notify you by email or through a prominent notice in the Services at least thirty (30) days before the effective date. Non-material changes take effect immediately upon posting. Your continued use of the Services after the effective date of a material change constitutes your acceptance of the updated policy.

We encourage you to review this Privacy Policy periodically. The "Last Updated" date at the top of this page indicates when the policy was most recently revised.

## 14. Contact Us

If you have questions, concerns, or requests regarding this Privacy Policy or our data practices, please contact us:

Allyx, Inc.\
Attn: Privacy Team\
1501 Yamato Rd\
2nd Floor #3030\
Boca Raton, FL 33431\
Email: legal@fairleadhq.com

**EU Representative (Article 27 GDPR):** TO BE APPOINTED. Until then, contact legal@fairleadhq.com.

**Data Protection Officer / UK Representative:** If Allyx is required to appoint a Data Protection Officer under GDPR Article 37, or a UK representative under the UK GDPR, the contact details will be provided here.

fairleadhq.com/legal/privacy

© 2026 Allyx, Inc. All rights reserved.

---

# Subprocessors

Canonical: https://fairleadhq.com/legal/subprocessors/

Updated: 2026-10-01
Publication state: published
Product version: platform

Agent summary: Subprocessors authorized to process customer personal data for the Fairlead platform, operated by Allyx, Inc., with location, purpose, and data processed for each.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


The third parties authorized to process customer personal data for the Fairlead platform.

## What is a Sub-processor?

"**Sub-processor**" means any third-party processor engaged by Allyx to process Customer Personal Data.

## Authorized Sub-processors

In order to provide our Services, Allyx, Inc. may engage third parties to carry out data-processing activities that involve access to customer data:

| Vendor | Location | Purpose |
|---|---|---|
| Google LLC | USA, EU | Infrastructure services; AI services; user analytics and marketing insights; identity provider for authentication |
| Axiom, Inc. | USA, EU | Observability and log management |
| Cloudflare, Inc. | USA, EU | A global edge platform, infrastructure services, AI services |
| GitHub | USA | Identity provider for authentication |
| Microsoft Corporation | USA | Identity provider for authentication |

fairleadhq.com/legal/subprocessors

© 2026 Allyx, Inc. All rights reserved.

---

# Terms of Service

Canonical: https://fairleadhq.com/legal/terms/

Updated: 2026-10-01
Publication state: published
Product version: platform

Agent summary: Terms of Service for the Fairlead platform, operated by Allyx, Inc. Terms that govern use of the Fairlead platform.

## Prerequisites

- None declared.

## Inputs

- None declared.

## Outputs

- None declared.

## Limitations

- None declared.

## Permissions

- None declared.

## Privacy

- None declared.


Terms that govern use of the Fairlead platform.

**IMPORTANT NOTICE:** These Terms of Service contain a binding arbitration clause and class action waiver in Section 16. Please read them carefully.

These Terms of Service ("**Terms**") constitute a legally binding agreement between Allyx, Inc., a Delaware corporation ("**Allyx**," "**we**," "**us**," or "**our**") and the entity or individual accepting these Terms ("**Customer**," "**you**," or "**your**").

By clicking "I agree," creating an account, or accessing or using the Allyx products, services, events, websites, and applications, you agree to be bound by these Terms. If you are entering into these Terms on behalf of a company or other legal entity, you represent and warrant that you have authority to bind that entity and its Affiliates to these Terms, and "Customer" refers to that entity. The Service is intended for business use by entities and by individuals who are at least 18 years of age; by accepting these Terms you represent that you meet this requirement.

If you do not agree to these Terms, do not use the Services.

## 1. Definitions

"**Affiliate**" means any entity that directly or indirectly controls, is controlled by, or is under common control with a party to these Terms. "Control" means direct or indirect ownership or control of more than fifty percent (50%) of the voting interests of the subject entity.

"**Authorized Users**" means Customer's employees, contractors, and agents who are authorized by Customer to access and use the Services under Customer's account.

"**Customer Data**" means all data, content, and information submitted to, collected by, accessed, or processed through the Services by or on behalf of Customer, including without limitation: application traces, logs, test session recordings, QA inputs and outputs, source code and repository contents accessed in connection with the Services (of which Allyx retains only Source Code Metadata, as described in Section 3.3), and Source Code Metadata.

"**Documentation**" means the technical and functional documentation for the Services made available by Allyx at website or as otherwise provided to Customer.

"**Fairlead**" or "**Fairlead platform**" or "**Platform**" means products, websites, applications, components, agents that Allix, Inc. Maintain and operate to provide Services.

"**Manifest Error**" means an obvious clerical, arithmetical, or computational error in Allyx's metering records that is demonstrably inconsistent with the underlying raw delivery data, such as a duplication of a line item, a transposition of figures, or a failure to apply an agreed discount or rate, and expressly excludes any dispute as to whether a result was validly delivered or whether Allyx's methodology for measuring outcomes is correct.

"**Order Form**" means a written or electronic order form, statement of work, or online checkout process that specifies the Service tier, fees, and other commercial terms agreed to by the parties.

"**Products**" means the individual products made available as part of the Fairlead platfrom, namely fairleadTest, fairleadFix, fairleadRebalance, fairleadReplay, and fairleadSelect (each a "Product"), together with any additional products Allyx may make available from time to time.

"**Services**" means products, services, events, websites, and applications provided by Allyx, Inc. as a part of Fairlead©️ platform or individually, together with all associated features, and any updates, enhancements, or modifications thereto.

"**Source Code Metadata**" means structural information derived from Customer's source code repositories, including file paths, class and method names, test names, commit hashes, coverage information, etc., but expressly excluding raw source code content.

"**Subscription Term**" means the period during which Customer has subscribed to the Services, as specified in the applicable Order Form or, for self-serve accounts, as indicated in the account dashboard.

## 2. Access to the Services

### 2.1 License Grant

Subject to Customer's compliance with these Terms and timely payment of all applicable fees, Allyx grants Customer a limited, non-exclusive, non-transferable, non-sublicensable right to access and use the Services during the Subscription Term solely for Customer's internal business purposes and in accordance with the Documentation.

### 2.2 Authorized Users

Customer may permit Authorized Users to access and use the Services. Customer is responsible for all acts and omissions of its Authorized Users and for ensuring that each Authorized User complies with these Terms. Customer shall promptly notify Allyx of any unauthorized access to or use of the Services.

### 2.3 Restrictions

Customer shall not, and shall not permit any third party to:

(a) copy, modify, adapt, translate, or create derivative works of the Services or Documentation;

(b) reverse engineer, disassemble, decompile, or otherwise attempt to derive the source code of the Services;

(c) sell, resell, sublicense, transfer, assign, or otherwise commercialize access to the Services to any third party;

(d) use the Services to develop or offer a product or service that competes with the Services, benchmark the Services against a third-party product, or use any output of the Services to train, develop, or improve a competing or substitute machine-learning model, product, or service;

(e) use the Services for timesharing, service bureau, or other commercial hosting purposes;

(f) remove, alter, or obscure any proprietary notices, labels, or marks on the Services or Documentation;

(g) use the Services in violation of any applicable law, regulation, or these Terms;

(h) use the Services in any manner that could damage, disable, overburden, or impair Allyx's infrastructure and systems; or

(i) use the Services in connection with any high-risk activity or system where failure or error could lead to death, personal injury, or severe physical or environmental damage (including medical, aerospace, nuclear, weapons, or autonomous-vehicle systems).

### 2.4 Third-Party Services and Customer-Provided Access

To use certain features, Customer connects, or provides Allyx with access to, Customer's own systems and third-party services, which may include source code repositories, CI/CD systems, issue and ticket trackers (such as Jira or GitHub Issues), and target application environments (including by installing Allyx's instrumentation agent and a secure tunnel) (collectively, "**Customer Systems and Integrations**").

Customer is solely responsible for: (a) obtaining and maintaining the third-party services, accounts, licenses, and consents required to connect them to the Services; (b) installing, configuring, and maintaining the connectivity, credentials, and access scopes that Allyx needs to perform the Services; and (c) the security and configuration of the access it grants. Customer represents and warrants that it has all rights and authority necessary to grant Allyx access to the Customer Systems and Integrations and to authorize the actions described in these Terms.

Allyx is not responsible for any third-party service, or for any failure, unavailability, or change of a third-party service, or for any act or omission of a third-party service provider. Customer's use of a third-party service is governed by that provider's terms.

Customer is responsible for obtaining, maintaining, and supporting all internet connectivity, equipment, and ancillary services needed to connect to and use the Services, including the connectivity required to establish and maintain the secure tunnel and instrumentation agent described in this Section 2.4. Customer and its Authorized Users must maintain the security of their account credentials and keep credentials confidential.

### 2.5 Beta, Trial, and Evaluation Use

Allyx may make the Services, or certain features or Products, available on a free, trial, beta, evaluation, or early-access basis ("**Evaluation Use**"). Evaluation Use is permitted only for Customer's internal evaluation and may be modified, suspended, or discontinued at any time. Notwithstanding any other provision of these Terms, Evaluation Use is provided "AS IS" and "AS AVAILABLE," without any warranty, support, indemnification, or service-level commitment, and Allyx's total liability arising from or relating to Evaluation Use shall not exceed one hundred U.S. dollars (US $100).

## 3. Customer Data

### 3.1 Customer Ownership

As between the parties, Customer retains all right, title, and interest in and to Customer Data. Allyx acquires no ownership rights in Customer Data.

### 3.2 License to Process Customer Data

Customer hereby grants Allyx a limited, non-exclusive, worldwide, royalty-free license to host, process, transmit, and display Customer Data solely as necessary to provide and support the Services during the Subscription Term, and as otherwise expressly permitted in these Terms.

### 3.3 Source Code Access

To enable certain features of the Fairlead platform (including, but not limited, fairleadSelect, fairleadRebalance, and fairleadFix), Customer may connect Customer's source code repositories to the Services. Customer grants Allyx read access to the connected repositories solely for the purpose of delivering the Services. This read access includes periodic re-analysis of the repository as needed to recalculate test coverage and keep fairleadSelect results current. Allyx's write access is limited to: (a) pushing feature branches to Customer's repository; and (b) creating pull requests for Customer's review, in each case only when Customer initiates a fairleadFix workflow or other products that require such action.

Allyx does not retain raw source code. Allyx retains only Source Code Metadata (file paths, class and method names, and commit hashes) in its systems, and only to the extent necessary to maintain coverage analysis and fairleadSelect and fairleadTest functionality.

### 3.4 Session Recording

Certain Services features (including fairleadReplay and fairleadFix) operate by recording the interactions that occur during QA test sessions, reproductions conducted by Customer's personnel or e2e tests executions. These recordings may capture the full range of information available in the browser developer tools and the instrumented environment, including network requests and responses (and their headers and contents), cookies and authentication tokens, console logs, user inputs, and application responses returned from Customer's backend systems (collectively, "**Session Recordings**"). Customer acknowledges and consents to this recording as an inherent part of the Services. Customer is solely responsible for ensuring that Session Recordings are conducted in environments and with data for which Customer has all necessary rights and authorizations under applicable law.

### 3.5 Customer Responsibilities Regarding Data

Customer represents and warrants that:

(a) Customer has all rights, licenses, and consents necessary to submit Customer Data to the Services and to authorize Allyx to process it as described in these Terms;

(b) Customer Data and Customer's use of the Services do not and will not violate any applicable law, regulation, or third-party right, including any data protection or privacy law; and

(c) Customer will not submit to the Service any special categories of sensitive personal data (as defined under applicable data protection law, including health, biometric, financial account credentials, or government identification numbers) unless Customer has entered into a separate written agreement with Allyx authorizing such use.

### 3.6 No Use for AI Training

Allyx will not use Customer Data to train, fine-tune, or improve any artificial intelligence or machine learning model, whether proprietary to Allyx or operated by a third party. Allyx may use aggregated, de-identified metrics derived from the Services (which do not contain Customer Data content) to improve the functionality and performance of the Services.

### 3.7 Data Retention and Deletion

During the Subscription Term, Allyx will retain Customer Data in accordance with the retention period specified in the applicable Order Form.

Upon termination or expiration of the Subscription Term, Allyx will, within thirty (30) days of the termination or expiration date, start irreversibly deleting all Customer Data from its systems and complete such deletion within sixty (60) days of the termination or expiration date, unless longer retention is required by applicable law.

### 3.8 Test Execution and Environment Interaction

To deliver the Services, Allyx executes generated tests, scenarios, and replays recorded sessions against the environment selected and connected by Customer (via the Customer-established secure tunnel or other connectivity provided by Customer). Customer acknowledges and agrees that such execution involves automated interaction with Customer's application and may create, modify, or delete data in the target environment, including by replicating the actions performed during recorded sessions. Customer is solely responsible for selecting the target environment, for providing any credentials required for test execution, and for all effects of test execution on that environment and the data within it. Allyx requires that Customer use strictly non-production environments to avoid data leakage and advises against instrumenting high-load environments. Customer authorizes Allyx to access and interact with the selected environment, using Customer-provided credentials, solely as necessary to perform the Services.

## 4. Intellectual Property

### 4.1 Allyx IP

Allyx retains all right, title, and interest in and to the Services, the Platform, the Products, the Documentation, all underlying software, algorithms, models, interfaces, and any improvements, enhancements, or modifications thereto, including all intellectual property rights. These Terms do not convey any ownership interest in the Services or the Products to Customer.

"Allyx", the Platform and the Product names (including fairleadTest, fairleadFix, fairleadRebalance, fairleadReplay, and fairleadSelect) and associated logos are trademarks of Allyx, Inc. Customer is granted no right or license to use any Allyx or Product trademark except as expressly authorized in writing by Allyx.

### 4.2 Feedback

If Customer provides Allyx with feedback, suggestions, or ideas regarding the Services ("**Feedback**"), Customer grants Allyx a perpetual, irrevocable, royalty-free, worldwide license to use, incorporate, and commercialize such Feedback in any manner without restriction, attribution, or compensation to Customer.

### 4.3 Aggregated Data

Allyx may collect and use aggregated, anonymized data about Services usage and performance, provided that such data does not identify Customer or any individual. Allyx retains all rights in such aggregated data.

### 4.4 Ownership of Deliverables

Notwithstanding Section 4.1, and as between the parties, Customer owns, upon delivery, all artifacts that Allyx delivers to Customer through the Services (collectively, "**Deliverables**"). Deliverables consist of: (a) generated source code, such as test code and bug-fix changes (diffs), delivered by pushing branches and opening pull requests in Customer's repositories; (b) pull-request comments and bug or ticket descriptions delivered into Customer's repositories or trackers; and (c) fairleadSelect outputs, such as lists of test names or identifiers returned through the Services or its APIs. Deliverables are delivered as plain code and content, and Allyx does not embed any Allyx software, libraries, frameworks, or tooling into the Deliverables. Accordingly, Customer's ownership of the Deliverables is not subject to any license-back of Allyx components.

Customer's ownership of the Deliverables does not grant Customer any right in the Services, the Platform, the Products, the AI workers, models, methods, methodologies, approaches or any other Allyx intellectual property used to produce the Deliverables, all of which remain Allyx's exclusive property under Section 4.1. Allyx further retains all rights in its general knowledge, skills, techniques, and know-how, including any improvements thereto developed in the course of providing the Services.

## 5. Fees and Payment

### 5.1 Outcome-Based Fees

Allyx charges for the Services on an outcome basis. Except for usage-based Products and committed-volume tiers described below, Fees are incurred upon Allyx's delivery of a result, including, as applicable: (a) each delivered test; (b) each delivered bug description; (c) each delivered bug fix; and (d) each replayed test. For fairleadSelect, Fees are charged on a usage basis (for example, per volume of requests per month). The applicable Fees, rates, and units are set forth in the applicable Order Form or Allyx's then-current pricing page. All Fees are quoted in U.S. dollars unless otherwise specified.

A result is "delivered" when Allyx makes it available to Customer, including by opening a pull request, creating a ticket, or returning a result through the Services. Fees are earned upon delivery and are not contingent on Customer's acceptance, review, merger of a pull request, or use of the result. A delivered result that Customer declines, does not merge, or otherwise rejects remains a delivered result and is chargeable.

### 5.2 Committed-Volume Tiers

Customer may subscribe to a committed-volume tier offering discounted per-outcome pricing in exchange for a minimum committed volume or spend over the applicable period, as set forth in the Order Form. Committed amounts are payable in full regardless of actual usage. Usage exceeding the committed volume is billed at the applicable tier or overage rate. Unused committed volume does not carry over to a subsequent period unless expressly stated in the Order Form.

### 5.3 Quality and Remediation

If Customer is dissatisfied with the quality of a delivered result, Customer's sole and exclusive remedy is to submit a support ticket, and Allyx will work in good faith to remediate the result (for example, by revising or regenerating it). Notwithstanding Section 8, dissatisfaction with, rejection of, or failure to use a delivered result does not entitle Customer to a refund or credit and does not waive the Fee for that result, except as Allyx may expressly agree in writing.

### 5.4 Payment Processing

Fees are processed through QuickBooks Payments or such other payment processor as Allyx may designate from time to time. Allyx does not store Customer credit card information. Payment processing is subject to the terms of the applicable payment processor.

Customer represents and warrants that: (a) the payment information Customer provides is accurate and complete; (b) Customer is authorized to use the selected payment method; (c) all charges incurred by Customer will be honored by Customer's payment provider; and (d) Customer will pay all Fees and applicable taxes in accordance with these Terms. Customer agrees to keep its payment and contact information current.

### 5.5 Invoicing and Payment Terms

Outcome-based and usage-based Fees are invoiced monthly in arrears based on the results delivered and usage metered during the period. Committed-volume tier Fees are invoiced in advance for each committed period. Payment is due within thirty (30) days of the invoice date unless otherwise specified in the Order Form.

### 5.6 Late Payment

Overdue amounts accrue interest at the rate of 1.5% per month (or the maximum rate permitted by applicable law, if lower). Allyx reserves the right to suspend Customer's access to the Services upon thirty (30) days' written notice if any Fees remain unpaid after the due date (or immediately if payment by credit card fails and is not cured within ten (10) days).

### 5.7 Taxes

Fees are exclusive of all taxes, levies, and duties imposed by taxing authorities. Customer is responsible for paying all applicable taxes (including VAT, GST, sales tax, and withholding taxes) arising from these Terms, excluding only taxes assessed on Allyx's net income.

### 5.8 Non-Refundable

Except as expressly set forth in these Terms or required by applicable law, all Fees paid are non-refundable.

### 5.9 Billing Disputes and Chargebacks

Customer must notify Allyx in writing of any good-faith dispute regarding an invoice within thirty (30) days of the invoice date, and the parties will work in good faith to resolve the dispute. Customer shall not initiate a payment-card chargeback or payment reversal for any amount owed without first following this billing-dispute process. Amounts that are charged back or reversed for properly delivered results remain due and payable.

### 5.10 Price Changes

Allyx may change its Fees at any time with at least thirty (30) days' notice to Customer prior to the next billing period. Customer's continued use of the Services after the effective date of a price change constitutes acceptance. If Customer does not agree to the new pricing, Customer may terminate the Services as provided in Section 7.

### 5.11 Metering and Records

Allyx meters the delivered outcomes and usage that determine Fees. Allyx's records of delivered outcomes and metered usage are the authoritative basis for invoicing, absent Manifest Error. Allyx will make summary metering information available to Customer on reasonable request, and the parties will resolve any good-faith metering discrepancy in accordance with Section 5.9.

## 6. Confidentiality

### 6.1 Definition

"**Confidential Information**" means any non-public information disclosed by one party ("Disclosing Party") to the other ("Receiving Party") in connection with these Terms that is designated as confidential or that reasonably should be understood to be confidential given the nature of the information and the circumstances of disclosure. Allyx's Confidential Information includes the Services, pricing, and product roadmap. Customer's Confidential Information includes Customer Data and source code. For the avoidance of doubt, Customer's source code (to the extent accessed under Section 3.3) is Customer's Confidential Information and is subject to the highest degree of protection under this Section.

### 6.2 Obligations

The Receiving Party shall: (a) use Confidential Information only for purposes of exercising its rights or fulfilling its obligations under these Terms; (b) protect Confidential Information with at least the same degree of care it uses to protect its own confidential information, and not less than reasonable care; and (c) not disclose Confidential Information to any third party without the prior written consent of the Disclosing Party, except to its and its Affiliates' employees, contractors, and agents who have a need to know and are bound by obligations of confidentiality at least as protective as those in this Section.

### 6.3 Exceptions

Confidentiality obligations do not apply to information that: (a) is or becomes publicly available through no fault of the Receiving Party; (b) was rightfully known to the Receiving Party without restriction before disclosure; (c) is rightfully received from a third party without restriction; or (d) is independently developed by the Receiving Party without use of Confidential Information.

### 6.4 Required Disclosure

If the Receiving Party is required to disclose Confidential Information by law or court order, it shall, to the extent legally permitted, provide the Disclosing Party with prompt prior written notice and cooperate with the Disclosing Party's efforts to seek a protective order or other appropriate remedy.

### 6.5 Survival

The obligations in this Section 6 survive termination or expiration of these Terms for a period of five (5) years, except with respect to trade secrets, for which the obligations survive indefinitely.

## 7. Term and Termination

### 7.1 Term

These Terms commence on the date Customer first accepts them and continue until all Subscription Terms have expired or been terminated.

### 7.2 Subscription Term and Renewal

Each Subscription Term renews automatically for successive periods equal to the initial Subscription Term unless either party provides written notice of non-renewal at least thirty (30) days before the end of the then-current Subscription Term.

### 7.3 Termination for Cause

Either party may terminate these Terms immediately upon written notice if:

(a) the other party materially breaches these Terms and fails to cure the breach within thirty (30) days after receiving written notice specifying the breach in reasonable detail (or immediately for breaches not capable of cure, including breach of Section 2.3 or Section 6); or

(b) the other party becomes insolvent, makes an assignment for the benefit of creditors, or becomes subject to bankruptcy, receivership, or similar proceedings.

In addition to the foregoing, Allyx may terminate these Terms upon thirty (30) days' written notice if Customer's actions, conduct, or use of the Services, in Allyx's reasonable judgment, pose material reputational, legal, or operational risks to Allyx or other users of the Services.

### 7.4 Effect of Termination

Upon termination or expiration of these Terms: (a) all licenses granted to Customer immediately terminate; (b) Customer shall cease all use of the Services; (c) each party shall, upon request, promptly return or destroy the other party's Confidential Information; (d) Customer may export Customer Data during the thirty (30) day export window described in Section 3.7; and (e) all accrued payment obligations survive termination.

If Allyx terminates for Customer's material breach, all Fees for the remaining Subscription Term become immediately due and payable. If Allyx terminates for its own material breach, Allyx will refund any prepaid Fees covering the period after the termination date.

### 7.5 Suspension

Allyx may suspend Customer's or an Authorized User's access to all or part of the Services, with notice where practicable, if Allyx reasonably determines that: (a) there is a material security risk to the Services, Allyx, or other customers; (b) Customer has materially breached these Terms or the Acceptable Use Policy; (c) Customer's use threatens the security, integrity, or availability of the Services; (d) suspension is required by law or to respond to a legal or governmental request; or (e) Fees are overdue as provided in Section 5.6. Allyx will limit the scope and duration of a suspension to what it reasonably considers necessary and will restore access promptly once the cause is resolved. Suspension does not relieve Customer of its payment obligations. Notwithstanding clause (e) above, Allyx will not suspend Customer's access solely for non-payment if Customer is actively disputing the relevant charges in good faith in accordance with Section 5.9 and is cooperating to resolve the dispute.

### 7.6 Survival

The following Sections survive termination or expiration: 1, 3.1, 3.6, 3.7, 4, 5 (for accrued obligations), 6, 7.4, 8, 9, 10, 11, 12, 13, 14, 15, 16, and 17.

## 8. Warranties

### 8.1 Limited Warranty (Order Form Customers Only)

This Section 8.1 applies only to Customer entities that have executed an Order Form with Allyx. For such customers, Allyx warrants that the Services will perform materially in accordance with the Documentation during the Subscription Term when used as intended and in accordance with these Terms. This warranty does not apply to self-serve customers (those without an executed Order Form), for whom the Services is provided solely on an "AS IS" and "AS AVAILABLE" basis under Section 8.3.

### 8.2 Exclusive Remedy

Where the warranty in Section 8.1 applies and the Services fails to conform to it, Customer's exclusive remedy, and Allyx's entire liability, is for Allyx to use commercially reasonable efforts to correct the non-conformance. If Allyx cannot correct a material non-conformance within thirty (30) days after receipt of written notice from Customer, Customer may terminate the affected subscription and receive a pro-rata refund of prepaid Fees for the unexpired portion.

### 8.3 Disclaimers

EXCEPT FOR THE LIMITED WARRANTY IN SECTION 8.1 (WHICH APPLIES ONLY TO CUSTOMERS WITH AN EXECUTED ORDER FORM), THE SERVICE IS PROVIDED "AS IS" AND "AS AVAILABLE." ALLYX AND ITS LICENSORS EXPRESSLY DISCLAIM ALL WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, NON-INFRINGEMENT, AND ANY WARRANTIES ARISING FROM COURSE OF DEALING OR USAGE OF TRADE. ALLYX DOES NOT WARRANT THAT THE SERVICE WILL BE UNINTERRUPTED, ERROR-FREE, OR FREE OF HARMFUL COMPONENTS, OR THAT ANY DEFECTS WILL BE CORRECTED.

### 8.4 Service Levels

The Services are provided without any service-level or uptime commitment unless a specific service-level agreement is set forth in an applicable Order Form. Allyx may perform scheduled or emergency maintenance from time to time and will use commercially reasonable efforts to limit any resulting disruption.

## 9. Indemnification

### 9.1 Indemnification by Allyx

Allyx shall defend Customer against any third-party claim alleging that the Services, as provided by Allyx and used in accordance with these Terms, infringes any patent, copyright, trademark, or trade secret of a third party, and shall indemnify Customer for all damages, costs, and reasonable attorneys' fees finally awarded by a court or agreed in settlement.

If the Service becomes, or in Allyx's opinion is likely to become, the subject of an infringement claim, Allyx may, at its option and expense: (i) procure for Customer the right to continue using the Services; (ii) modify or replace the Services so that it is non-infringing while substantially preserving its functionality; or (iii) if neither (i) nor (ii) is commercially reasonable, terminate the affected Services and refund any prepaid Fees for the unused portion. This Section 9.1 states Allyx's entire liability, and Customer's sole and exclusive remedy, for any claim of intellectual-property infringement.

Allyx's obligations under this Section do not apply to the extent a claim arises from: (a) Customer Data; (b) Customer's modification of the Services; (c) Customer's combination of the Services with products, data, or services not provided by Allyx; (d) Customer's use of the Services after receiving notice to discontinue; (e) Customer's breach of these Terms; (f) the Deliverables or any AI Output (as defined in Section 17), which are addressed in Section 17; or (g) any combination, modification, or use of a Deliverable by or on behalf of Customer.

### 9.2 Indemnification by Customer

Customer shall defend Allyx and its Affiliates, and each of their respective officers, directors, employees, contractors, and agents, against any third-party claim arising from: (a) Customer Data, including any allegation that Customer Data infringes a third-party right or violates any applicable law; (b) Customer's or any Authorized User's use of the Services in violation of these Terms; (c) any violation of applicable data protection law by Customer in connection with its use of the Services; or (d) any third-party claim arising from content Customer submits through Session Recordings. Customer shall indemnify Allyx for all damages, costs, and reasonable attorneys' fees finally awarded or agreed in settlement.

### 9.3 Indemnification Procedure

The indemnified party must: (a) promptly notify the indemnifying party in writing of the claim; (b) grant the indemnifying party sole control over the defense and settlement of the claim; and (c) provide reasonable cooperation. The indemnifying party shall not settle any claim in a manner that imposes liability or obligation on the indemnified party without prior written consent. The indemnified party may participate in the defense at its own expense.

## 10. Limitation of Liability

### 10.1 Exclusion of Damages

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL EITHER PARTY BE LIABLE TO THE OTHER FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES, INCLUDING LOSS OF PROFITS, LOSS OF REVENUE, LOSS OF DATA, BUSINESS INTERRUPTION, OR COST OF SUBSTITUTE GOODS OR SERVICES, ARISING OUT OF OR RELATED TO THESE TERMS OR THE SERVICE, REGARDLESS OF CAUSE AND REGARDLESS OF WHETHER THE PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

### 10.2 Liability Cap

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, EACH PARTY'S TOTAL CUMULATIVE LIABILITY TO THE OTHER PARTY ARISING OUT OF OR RELATED TO THESE TERMS, WHETHER IN CONTRACT, TORT, STRICT LIABILITY, OR ANY OTHER THEORY, SHALL NOT EXCEED THE TOTAL FEES PAID BY CUSTOMER TO ALLYX IN THE TWELVE (12) MONTHS IMMEDIATELY PRECEDING THE EVENT GIVING RISE TO THE CLAIM.

### 10.3 Exceptions

The exclusions and limitations in Sections 10.1 and 10.2 do not apply to: (a) Customer's payment obligations under Section 5; (b) damages caused by fraud or willful misconduct; or (c) Customer's breach of the license scope or use restrictions in Section 2 (including Section 2.3).

### 10.4 Basis of Bargain

The parties acknowledge that the limitations in this Section 10 reflect a reasonable allocation of risk and are an essential element of the basis of the bargain between the parties. Allyx would not enter into these Terms without these limitations.

## 11. Data Protection

To the extent Allyx processes personal data on Customer's behalf in connection with the Services, such processing is governed by Allyx's Data Processing Agreement ("**DPA**"), which is incorporated into and forms part of these Terms. For enterprise customers, the DPA is available as a separately executed agreement. For self-serve customers, the DPA is made available at [fairleadhq.com/legal/dpa](https://fairleadhq.com/legal/dpa/) and is incorporated by reference into these Terms.

Nothing in these Terms shall be interpreted to conflict with the DPA; in the event of a conflict, the DPA shall prevail with respect to data protection matters.

## 12. Security

Allyx implements and maintains commercially reasonable administrative, technical, and physical security measures designed to protect Customer Data against unauthorized access, disclosure, or destruction. These measures include encryption of Customer Data in transit (TLS) and at rest (AES-256).

Allyx shall notify Customer in writing of any confirmed unauthorized access to Customer Data and shall provide reasonable cooperation in Customer's investigation and mitigation. Where such an event constitutes a Security Incident affecting personal data, Allyx's notification obligations and timelines are governed by the DPA (including the seventy-two (72) hour notification commitment), which controls in the event of any conflict with this Section.

Customer is responsible for maintaining the security of its account credentials and for all activity that occurs under Customer's account.

## 13. Acceptable Use

Customer's use of the Services is subject to Allyx's Acceptable Use Policy, available at [fairleadhq.com/legal/aup](https://fairleadhq.com/legal/aup/), which is incorporated into these Terms by reference. In the event of a conflict between the Acceptable Use Policy and these Terms, these Terms control.

## 14. Changes to the Service and Terms

### 14.1 Changes to the Service

Allyx may modify, update, or discontinue features of the Services at any time. Allyx will use commercially reasonable efforts to provide advance notice of material discontinuations that adversely affect Customer.

### 14.2 Changes to These Terms

Allyx may update these Terms from time to time. For self-serve customers, Allyx will provide at least thirty (30) days' prior notice of material changes via email or in-product notification. Continued use of the Services after the effective date of any change constitutes acceptance. If Customer objects to a material change, Customer's sole remedy is to terminate the Services as provided in Section 7 before the effective date of the change.

Enterprise customers with executed Order Forms are not subject to material changes to these Terms until the expiration or renewal of their then-current Subscription Term.

## 15. General Provisions

### 15.1 Entire Agreement

These Terms, together with all Order Forms, the DPA, the Acceptable Use Policy, the Privacy Policy, and any other policies incorporated by reference, constitute the entire agreement between the parties with respect to the Services and supersede all prior agreements, representations, and understandings relating to the same subject matter. These Terms apply to the exclusion of, and Allyx expressly rejects, any additional or conflicting terms in a Customer purchase order, vendor-onboarding form, or similar document, which have no effect even if Allyx accepts payment referencing them.

### 15.2 Order of Precedence

In the event of a conflict, the order of precedence is: (1) the executed Order Form; (2) the DPA (for data protection matters); (3) these Terms; (4) the Acceptable Use Policy.

### 15.3 Assignment

Customer may not assign or transfer these Terms or any rights hereunder without Allyx's prior written consent, except that Customer may assign these Terms without consent in connection with a merger, acquisition, or sale of all or substantially all of Customer's assets, provided that (a) the assignee is not a competitor of Allyx and (b) Customer provides Allyx with written notice of the assignment prior to its effectiveness. Allyx may assign these Terms without restriction in connection with a merger, reorganization, change of control, or asset sale. Any purported assignment in violation of this Section is void.

### 15.4 Force Majeure

Neither party is liable for delays or failures in performance resulting from causes beyond its reasonable control, including natural disasters, government actions, pandemics, power outages, or internet disruptions, provided that the affected party gives prompt written notice and uses reasonable efforts to resume performance. Notwithstanding the foregoing, a party's obligation to pay any amounts already due and owing under these Terms is not excused by a force majeure event.

### 15.5 Waiver and Severability

Failure to enforce any provision of these Terms is not a waiver of that right. If any provision is found to be unenforceable, it shall be modified to the minimum extent necessary to make it enforceable, and the remaining provisions shall continue in full force and effect.

### 15.6 Notices

Notices to Allyx shall be sent to: legal@fairleadhq.com. Notices to Customer shall be sent to the email address associated with Customer's account. Notices are effective upon receipt.

### 15.7 Relationship of the Parties

The parties are independent contractors. Nothing in these Terms creates a partnership, joint venture, agency, employment, or franchise relationship between the parties.

### 15.8 Compliance with Laws

Allyx will comply with all applicable U.S. federal and state laws and regulations in its operation and provision of the Services, and reserves the right to disclose information as necessary to comply with applicable legal obligations. Customer shall comply with all applicable laws and regulations governing Customer's use of the Services, including all applicable export control and sanctions laws. Customer represents that it is not on any U.S. government restricted parties list and will not use the Services in any country subject to U.S. embargo.

### 15.9 U.S. Government Rights

If Customer is a U.S. government entity, the Services is "commercial computer software" and "commercial computer software documentation" as those terms are defined in 48 C.F.R. § 2.101, and the government's rights in the Services are limited to those granted to all other customers under these Terms.

### 15.10 Publicity

Allyx may identify Customer as a customer and use Customer's name and logo in Allyx's customer lists and marketing materials, in accordance with any trademark usage guidelines Customer provides to Allyx. Customer may opt out of, or revoke, this use at any time by written notice to Allyx, which will apply prospectively.

### 15.11 No Third-Party Beneficiaries

Nothing in these Terms, express or implied, is intended to or shall confer upon any third-party person or entity any right, benefit, or remedy of any nature whatsoever under or by reason of these Terms.

### 15.12 Limitation Period on Claims

Except for claims arising from non-payment of Fees or breach of a party's intellectual property or confidentiality obligations, no action arising out of or relating to these Terms may be brought by either party more than one (1) year after the cause of action first accrued.

### 15.13 Counterparts

These Terms, together with any Order Form, may be executed in one or more counterparts, each of which shall be deemed an original and all of which together shall constitute the same instrument. Electronic signatures shall be deemed equivalent to original signatures for all purposes.

### 15.14 Authority

Each party represents and warrants that it has full legal authority to enter into these Terms and to be bound by its obligations hereunder. Customer further represents and warrants that it has the authority to bind its Affiliates to these Terms and will ensure their compliance with these Terms.

## 16. Governing Law and Dispute Resolution

### 16.1 Governing Law

These Terms are governed by the laws of the State of Delaware, without regard to its conflict of law principles. These Terms are for the provision of services and not a sale of goods. The Uniform Commercial Code, the Uniform Computer Information Transactions Act, and the United Nations Convention on Contracts for the International Sale of Goods do not apply to these Terms.

### 16.2 Enterprise Customers — Court Jurisdiction

For Customer entities that have executed an Order Form with Allyx, any dispute arising out of or relating to these Terms shall be submitted to the exclusive jurisdiction of the state and federal courts located in the State of Delaware, and each party irrevocably consents to such jurisdiction.

### 16.3 Pre-Arbitration Escalation

Before either party may initiate arbitration under Section 16.4 or file for litigation under Section 16.2 (except for claims seeking emergency equitable relief under Section 16.5), the party seeking to resolve the dispute must deliver written notice to the other party describing the nature of the dispute and the relief sought (a "**Notice of Dispute**"). Within ten (10) business days of delivery of the Notice of Dispute, senior representatives of each party with authority to resolve the matter shall meet by telephone or videoconference and attempt in good faith to negotiate a resolution. If the dispute is not resolved within twenty (20) business days of the date of the Notice of Dispute (or such longer period as the parties may agree in writing), either party may pursue the applicable remedies set forth in this Section 16.

### 16.4 Self-Serve Customers — Binding Arbitration

For Customer individuals or entities accessing the Services through a self-serve account (without an executed Order Form), any dispute arising out of or relating to these Terms shall be resolved by binding arbitration administered by JAMS under its Streamlined Arbitration Rules and Procedures, with the arbitration conducted in Boca Raton, Florida (or by videoconference at the request of either party). Judgment on the arbitration award may be entered in any court of competent jurisdiction. The parties expressly waive any right to a jury trial.

CLASS ACTION WAIVER: CUSTOMER WAIVES ANY RIGHT TO BRING OR PARTICIPATE IN A CLASS ACTION, COLLECTIVE ACTION, OR REPRESENTATIVE ACTION IN CONNECTION WITH ANY DISPUTE ARISING UNDER THESE TERMS.

### 16.5 Small Claims; Equitable Relief

Nothing in this Section prevents either party from seeking relief in small claims court for disputes within that court's jurisdiction, or from seeking emergency equitable relief (including injunctive relief) in any court of competent jurisdiction to prevent irreparable harm pending arbitration.

## 17. Artificial Intelligence Terms

### 17.1 AI-Powered Features

The Services uses artificial intelligence, including large language models, to deliver certain Products and features (including fairleadTest, fairleadFix, fairleadRebalance, and fairleadReplay). The inputs Customer provides or that the Services derives from Customer Data, and the content the Services generates (including generated test code, bug-fix changes, and ticket content, collectively the "**AI Output**"), are addressed in this Section 17 and, as to ownership, in Section 4.4.

### 17.2 Nature of AI Output; No Reliance Without Review

AI Output is generated by probabilistic models and may be inaccurate, incomplete, biased, non-functional, or unsuitable for Customer's purposes, and may be similar or identical to output generated for other customers. AI Output is provided to assist Customer and is not a substitute for professional judgment. Customer is solely responsible for reviewing, testing, and validating all AI Output — including having a qualified developer evaluate any generated code for correctness, security, and fitness — before relying on, merging, or deploying it. Allyx does not warrant the accuracy, completeness, or fitness of any AI Output.

### 17.3 Autonomous and Automated Actions

The AI-powered features operate in an automated and, in some cases, autonomous manner — including by analyzing source code, generating and pushing branches, opening pull requests, creating tickets, and executing tests against the environment Customer connects (see Section 3.8). Customer authorizes these actions, is responsible for configuring and limiting the access and permission scopes granted to the Services, and is responsible for the outcomes of the actions it permits. Customer is responsible for maintaining appropriate human oversight and approval gates for any action that affects Customer's systems or data.

### 17.4 No Training on Customer Data

As set out in Section 3.6, Allyx does not use Customer Data to train, fine-tune, or improve any AI or machine-learning model.

### 17.5 AI Sub-processors and Model Changes

Allyx uses third-party AI models as sub-processors to deliver the AI-powered features, as identified in the DPA and the sub-processor list at [fairleadhq.com/legal/subprocessors](https://fairleadhq.com/legal/subprocessors/). Allyx may add, remove, or change the AI models or providers it uses for technical, operational, security, or legal reasons, provided that Allyx does not thereby materially reduce the functionality of the Services. Sub-processor changes are handled as provided in the DPA.

### 17.6 Indemnity and Liability for AI Output

Notwithstanding Section 9.1, Allyx's intellectual-property indemnity applies to the Services itself but does not apply to AI Output or the Deliverables. Allyx is not liable for any claim, loss, or damage arising from Customer's use of, or reliance on, AI Output, and any liability that does arise remains subject to the limitations in Section 10. Customer's prohibition on submitting special-category or sensitive data to the AI-powered features is set out in Section 3.5(c).

fairleadhq.com/legal/terms

© 2026 Allyx, Inc. All rights reserved.

---

# Fairlead Recorder Extension Privacy Policy

Canonical: https://fairleadhq.com/privacy/

Updated: 2026-10-07
Publication state: published
Product version: chrome-web-store

Agent summary: Recorder without sign-in sends no recordings, usage analytics, telemetry, or diagnostic reports to Fairlead. Capture, review, and export run locally. This policy explains local data, storage, exports, and review before sharing; the platform Privacy Policy covers accounts and connected services.

## Prerequisites

- The Fairlead Recorder extension

## Inputs

- Activity in the recorded page
- Browser diagnostics
- Images and written information you add

## Outputs

- Local session evidence
- Downloaded files

## Limitations

- Automatic redaction does not identify every sensitive value
- Downloaded copies must be reviewed and deleted separately

## Permissions

- debugger
- tabs
- webNavigation
- scripting
- storage
- downloads
- alarms
- sidePanel
- offscreen
- clipboardRead
- identity
- Host permissions

## Privacy

- No data sent to Fairlead in mode without sign-in
- No usage analytics or telemetry in that mode
- Local storage and export
- Review evidence before sharing


When you use Recorder without signing in, nothing is sent to Fairlead. Learn what stays on your device and what to review before sharing exports.

Allyx, Inc. ("**Allyx**," "**we**," "**us**," or "**our**") provides the Fairlead Recorder browser extension ("**Recorder**"). This policy explains how Recorder handles information when you use it **without signing in**.

**In this mode, Recorder sends no data to Fairlead.** Recording, review, and export take place on your device. We receive no recordings, usage analytics, telemetry, or diagnostic reports from Recorder, and we have no access to your local evidence.

Our [platform Privacy Policy](https://fairleadhq.com/legal/privacy/) covers Fairlead accounts, connected product features, our websites, and information you send us, including support requests. This Recorder policy supplements it for local use without sign-in.

## 1. Use Without Signing In

Select **Continue without an account** to use Recorder locally. No Fairlead account or connection to the Fairlead platform is required.

Recorder keeps captured data in browser memory and local browser storage. It does not upload recordings, report how you use the extension, or add Fairlead tracking or correlation headers to the website's requests. Generating and downloading evidence also happens locally.

The website you test continues to make its own network requests. If you choose to re-download an image in the viewer, Recorder requests it from its source website. Your browser, websites you visit, and tools you use to share files handle information under their own policies.

## 2. Information Recorder Captures Locally

Recorder captures evidence to help you document test execution, reproduce bugs, and verify fixes. Select **Start recording** to begin and **Stop recording** to end capture. Recorder captures the selected tab and can follow a new tab opened from it. The panel also reads the active page's address to show where recording will start.

Depending on the page and available browser data, a recording can include:

- **Page activity:** clicks, navigation, scrolling, selected keyboard events, form values, selected text, file names and properties, and details of page elements and changes.
- **Network activity:** request and response URLs, headers, cookies, available bodies, timings, and WebSocket messages.
- **Diagnostics:** console messages, errors, stack traces, browser logs, and performance measurements. Some buffered performance measurements may relate to activity before recording started.
- **Browser context:** browser version, page address, viewport size, language, display preferences, and connection information exposed by the browser.
- **Images and written information:** screenshots you take, images you attach or paste, captured image previews, and titles, descriptions, notes, or annotations you add.

This information stays on your device in local mode. It can include personal data, passwords, tokens, or confidential content from the application you test.

## 3. Files You Export

Recorder generates files on your device and saves them to your browser's download location. Downloading does not send them to Fairlead.

| File | Contents |
| --- | --- |
| `network.har` | Captured HTTP requests and responses, including headers and available body content |
| `console.log` | Console messages and stack traces |
| `steps.json`, `playwright.spec.ts`, `puppeteer.js` | Recorded actions as browser automation steps or scripts, which can include URLs, selectors, and input values |
| `session.md` | Session title, description, browser and timing information, recorded actions, and evidence summary |
| `notes.md` | Saved notes and pins with their evidence context; included when present |
| `screenshots/*.png` | Screenshot and image attachments |

Files depend on the evidence available. The download is a folder of files and does not contain everything shown in the viewer.

You decide which files to share and with whom. Uploading them to an issue tracker, sending them to another person, or saving them in a synced folder places copies outside Recorder's local storage.

## 4. Review Before Downloading or Sharing

Before downloading a report, review the captured information and redact sensitive details where needed. Automatic redaction does not identify every sensitive value.

Recorder masks password fields and common credential fields by default. You can review supported fields and make additional redaction choices. Original values can remain in local storage for review; choosing **Unredact** can include an original value in an export.

Console text, screenshots, and information you write are not automatically redacted. Inspect request and response bodies, URLs, input values, notes, and images. Downloads can include images marked **Exclude from report** or **Outside recorded period**, so check the actual screenshot folder before sharing it.

Review the exported files before submitting or sharing them. Record only information you are authorized to handle and share only the evidence your recipient needs.

## 5. Local Storage and Deletion

Recorder keeps the current session in memory and browser session storage so you can review it after stopping. Images are stored separately in a local browser database. Preferences, such as appearance and your choice to continue without an account, are also stored locally.

Starting a **New recording** clears the previous session and its stored attachments. Browser session storage is cleared when the browser restarts; stored images have a separate cleanup process, so closing the browser is not a way to delete all local evidence.

Downloaded files remain where you saved them until you delete them. Clearing a session or uninstalling Recorder does not delete downloads or copies you have shared. Their security depends on your device and the storage or sharing services you choose. Allyx cannot retrieve, restore, or delete evidence held only on your device.

## 6. Chrome Web Store User Data Policy

Recorder complies with the [Chrome Web Store User Data Policy](https://developer.chrome.com/docs/webstore/program-policies/policies#protecting-user-privacy), including its [Limited Use requirements](https://developer.chrome.com/docs/webstore/program-policies/limited-use). These restrictions also apply to Recorder data shared through connected features covered by the platform Privacy Policy.

## 7. Contact and Policy Updates

For questions about this policy, contact [legal@fairleadhq.com](mailto:legal@fairleadhq.com). Policy updates follow the notice process in [Section 13 of the platform Privacy Policy](https://fairleadhq.com/legal/privacy/#13-changes-to-this-privacy-policy). The revision date appears at the top of this page.

---

# ROI calculator

Canonical: https://fairleadhq.com/roi/


Compare modeled bug-fixing and unit-test economics over twelve months.

[Open the interactive calculator](https://fairleadhq.com/roi/) to change inputs and inspect the charts. This Markdown snapshot does not run scenarios submitted by an agent.

## Request a report

Submit your name, job title, company, corporate email and project name alongside all calculator parameters. Email consent is required and unchecked by default. Requests are saved for follow-up; no report is downloaded.

## Default inputs

| Parameter | Value | Meaning |
| --- | --- | --- |
| Lines of code | 1000000  | The codebase this team maintains. |
| Developers on the team | 11  | People who write and fix this code. |
| Developer salary a year | 150000 USD | All in cost of one developer. |
| Coverage today | 15 % | Where the codebase starts. |
| Time spent on unit tests | 20 % | Share of developer time that goes on writing them. It sets how many tests the team writes by hand, so it counts only with equal scope off. |
| Coverage wanted | 80 % | Where it should get to. |
| Value of a test | 233 USD | What one escaped bug costs you, per test that would have caught it. |
| Time spent fixing bugs | 25 % | Share of the team that goes on bugs rather than new work. |
| Net codebase growth a month | 3 % | Net increase in codebase size. Rewriting existing code does not count as growth. |
| Bugs per new commit | 21.5 % | How often a change brings a defect with it. It sets how many bugs come in each month. |
| Tokens a bug, local agent | 3 millions | What a local agentic tool burns on one fix. |

Equal scope is on: every approach is priced to deliver the same work. With equal scope off, output is limited by each approach’s modeled capacity.

## Default model results

- Unit tests, first year return: +429%
- Bug fixing, modeled ROI: +159%
- Estimated cost avoided over 12 months, both models: $1,009,107

## Bug fixing

- What the same bugs cost: Cumulative spend on fixing them.
- Bugs fixed: Every approach resolves the full bug load with added capacity.
- Bug-fixing cost avoided: Difference from manual cost at the selected comparison scope.
- Bugs still open: Added capacity absorbs the full bug load. No bugs remain unresolved.

## Unit tests

- How fast coverage arrives: Every approach is priced to deliver these same tests, so they all follow this one curve. What separates them is the cost of getting here.
- What it costs to get there: Cumulative spend on writing and keeping those tests.
- What that leaves you: Value of the bugs those tests prevent, net of what they cost.
- Developer time not spent: Cumulative hours, against writing the same tests by hand.

## Bug-fixing assumptions

Model assumptions: 7.023 hours of manual work per bug, $15 per successful Fairlead fix, 75% success and manual fallback for the rest. AI-augmented work assumes 10% less direct effort. Semi-autonomous work assumes 55% less direct effort and 75% success.

The cost model includes 15 minutes of human review per resolved bug in all four approaches, manual fallback, context switching and release overhead. It excludes QA acceptance, setup and infrastructure.

The projection starts with an initial month’s bug load, then adds new bugs in months 1 through 12. It includes thirteen monthly bug loads in total. Like-for-like adds capacity to resolve the full bug load. With it off, manual and assisted capacity includes review time. Agent paths assume capacity for human fallback.

ROI = (manual cost − Fairlead cost) / Fairlead cost.

## Limits

Results depend on the assumptions and inputs. Use your own costs and workload to assess applicability. Currency values are USD. Pricing and product availability are described separately in [pricing](https://fairleadhq.com/pricing/) and the [platform overview](https://fairleadhq.com/platform/).