Title and description
Write the title as an observable failure in a specific area. A useful pattern is: product area, action, unexpected result, and important condition. "Export button does nothing" is better than "Export broken," while "CSV export stalls after selecting all date ranges in Chrome 138" is better when those conditions are already confirmed.
The description explains the goal and the effect of the failure. State what the reporter was trying to complete, where the process stopped, and whether data, money, access, or trust was affected. Do not repeat the title with more words. Give the investigator the context needed to understand why the behavior matters.
Steps to reproduce
Number each action and begin from a known state. Include the relevant role, account condition, sample input, page, and action that triggers the bug. One action per step makes it clear where observed behavior diverges. If setup data is required, provide a safe sample or instructions for creating it.
Test the sequence once before submitting when doing so is safe. Remove steps that do not affect the outcome. If the issue is intermittent, record several attempts and the approximate hit rate. A sequence that fails two times in ten is more useful than a label that says it happens sometimes.
Expected and actual result
Expected result states the behavior the product promise, interface, documentation, or prior version supports. Be concrete. Instead of saying the page should work, say that selecting Export should download one CSV containing the chosen date range.
Actual result records what happened instead. Include exact error text, final state, missing output, duplicated action, or timing. Do not replace observation with a suspected cause. "The request returned 504 after 30 seconds" is evidence. "The database is overloaded" is a hypothesis unless the reporter verified it.
Environment
Environment narrows the conditions. Record device type or model, operating system and version, browser and version, app or build version, and screen size. For an API or server issue, replace the irrelevant display fields with endpoint, client version, deployment region, runtime, and request identifier.
Versions matter more than labels such as latest. The latest build changes over time, while an exact value remains useful after the product moves on. If the report was tested in a second browser or device, state whether the result changed. That comparison can reduce the search area before engineering begins.
Severity and priority
Severity describes how badly the bug affects the product or user. Priority describes when the team should address the bug relative to other work. Keep them as separate fields because impact and sequence answer different questions.
A critical-severity issue may cause data loss, security exposure, or a broad inability to use a core workflow. High may block a major task without a reasonable workaround. Medium disrupts a workflow but leaves an alternative. Low is narrow, cosmetic, or mildly inconvenient. Adapt these definitions to the product and publish them beside the form.
Priority incorporates severity plus reach, customer commitments, launch timing, available workarounds, engineering risk, and opportunity cost. Triage should own the final priority. A reporter can suggest severity from their experience, but should not be required to understand the entire product queue.
Reproducibility, URL, and attachments
Mark whether the bug happens always, intermittently, or only once. Include the number of attempts for intermittent behavior. Paste the exact page URL after removing tokens and sensitive query values. The path, object type, and safe parameters can reveal a route-specific failure that a homepage link would hide.
Choose attachments for the question they answer. A screenshot records visual state. A screen recording preserves actions, timing, and transitions. Console and network logs show client and request failures. A stack trace identifies the failing execution path. Add timestamps so evidence from several systems can be compared.
Reporter, date, workaround, and context
Reporter information gives triage a path to ask a focused follow-up. Record the observation date and time zone when logs or deployments may matter. If the reporter needs privacy, use the supported contact process rather than placing personal information in a public issue.
A workaround helps support serve affected customers while the fix is evaluated. State the exact alternative and its limits. Write None known when there is no workaround. Additional context can include account state, affected users, a recent configuration change, a related release, or similar reports that do not fit a more specific field.
