A reproducible bug report

A useful bug report lets another person reproduce an unexpected result. Start with a title that names the affected action and the symptom. Include the application version, browser or operating system only when they help explain the issue. A statement such as export downloads an empty file is more actionable than the site is broken. Write numbered steps from a known starting point. Use a test account and invented sample values, not a real customer record. Describe what you expected and what actually happened in separate sections. If the result occurs intermittently, record how often you observed it instead of describing it as an absolute failure. Reduce the example before sharing it. Remove unrelated code, large logs and repeated screenshots. Keep enough detail to reproduce the behavior without removing the condition that causes it. A useful minimal example may be a few lines of JSON or a short sequence of clicks. Check attachments and logs for tokens, email addresses, internal hostnames and other information the recipient does not need. Never place a live session cookie in a report. If the problem involves access control, use the appropriate private security reporting channel instead of broadly sharing the details. Finish with impact and any temporary workaround you actually tested. Avoid guessing at the root cause. A clear account of observations is more helpful than a confident but unsupported diagnosis.

Title: [action and symptom]
Environment: [relevant version and platform]

Steps to reproduce
1. [starting point]
2. [action]
3. [action]

Expected result
[expected behavior]

Actual result
[observed behavior]

Frequency: [always / sometimes, observations]
Impact: [who or what is affected]
Tested workaround: [workaround or none]
Safe sample: [minimal example]