The goal of a bug report is not to prove that something is broken. The goal is to give engineering enough context to reproduce the problem, understand the blast radius, and decide what to do next.
Title:
Short summary:
Reporter:
Customer or account affected:
Product area:
Environment:
Steps to reproduce:
Expected behavior:
Actual behavior:
Frequency:
First seen:
Recent deploy or change:
Severity:
Priority:
Evidence:
Workaround:
Suggested owner:
What to include
Reproduction steps
Write the smallest set of steps that reliably triggers the issue. If the bug is intermittent, include what was happening before it appeared.
Expected and actual behavior
Separate what the user expected from what the product actually did. This helps remove ambiguity from the report.
Impact and severity
Capture who is affected, how often the issue happens, whether there is a workaround, and whether money, data, trust, or accessibility is at risk.
Evidence
Add screenshots, screen recordings, logs, session replay links, browser details, account identifiers, and support ticket links when available.
pagemarkr angle: A strong intake system should make the evidence mandatory before a report reaches sprint planning.
Next step
Use the template above for your current workflow, or request access to pagemarkr to turn bug intake into a repeatable system.