Fewer “can't reproduce” tickets

Getting bug reports you can act on

The expensive part of most bugs is not the fix, it is working out what the reporter saw. A recording from the person who hit it gives you the page, the exact steps, the timing, and — because they talk while they record — what they expected to happen.

The simplest change is to ask for it. Add a recording field to your issue template, and point reporters to how to report a bug with Sayvio. Here is a template you can paste into .github/ISSUE_TEMPLATE, Linear or Jira:

## What happened
<!-- One line. -->

## Recording
<!-- Paste a Sayvio link: start before the bug, reproduce it, say what you expected. -->

## Expected

## Actual

## Where
- URL:
- Browser and OS:
- Happens: every time / sometimes / once

A recording is a link, so it works in any tracker. Sayvio has no tracker integration: the link goes in the issue by hand.

Explaining your own work

• Pull request walkthroughs: record the feature working, and talk through the one part of the diff that needs a careful review. Put the link in the PR description.
• QA handoff: show the tester the change, the edge cases you already tried, and where you are least confident.
• Answering “how does this work?”: one recording instead of the same explanation in three chat threads.
• Reporting upstream: when a library or API misbehaves, a recording in the issue shows the maintainer the behaviour directly.

What it records, and what it doesn't

A browser tab, a window or your whole screen, with microphone, system audio and an optional camera bubble, and drawing on the page while you record. When you stop, it uploads and the share link is copied.

It does not capture console output, network traffic, storage or device details. When they matter, keep DevTools open on screen during the recording — the Console or Network panel in the video is often enough — or paste the logs into the issue alongside the link.