How to Add a Focused Screen Recording to a GitHub Issue

A recording is excellent for motion, timing, focus, animation, and transient UI states that are difficult to capture in a screenshot. It is poor at replacing searchable environment details, exact input values, error text, logs, and step-by-step reproduction instructions. A useful issue contains both forms of evidence.

Place the Save Replay link near the reproduction steps with a sentence such as 'At 0:12 the modal closes before the request finishes.' The sentence gives reviewers a reason to open the video and a specific detail to verify instead of forcing them to infer the purpose from an unexplained URL.

Start from a clean test state and capture one run. Hide API keys, tokens, email addresses, customer records, private repository names, browser tabs, notification previews, clipboard tools, and terminal output outside the bug. Use dummy data whenever the real data is not necessary to demonstrate the problem.

Trim the beginning to the first relevant state and the end to a brief pause after the visible result. If two unrelated defects appear, create two clips and two explanations. Short, single-purpose evidence is easier to review, replay, discuss, and later remove when it is no longer needed.

A public GitHub issue does not automatically mean the video should be public and indexable. Review whether the clip contains anything beyond the intended report. An unlisted Save Replay link is excluded from intentional search discovery but can still be forwarded by anyone with the URL.

Use password-protected access when a shared secret is appropriate, and remember that owner-private clips cannot be watched by other issue participants. Confirm the chosen mode in a signed-out browser before submitting the issue. If the recording contains secrets, remove it and rotate the exposed credentials rather than relying on visibility alone.