How detailed should reproduction steps be?

Detailed enough that someone unfamiliar with the feature can reproduce the bug on their first attempt. Number each step. Start from a clear entry point (e.g., "Navigate to Dashboard → Settings"). Include specific test data if relevant.

When should I set a bug as High vs. Critical priority?

Critical: the feature is completely broken for all users with no workaround. High: the feature is broken for some users or has a reasonable workaround. Medium: it works but incorrectly. Low: cosmetic or edge case.

Should bug tickets include a suggested fix?

Only if you're confident and it's brief. A one-line hint like "Likely the Nginx upload_max_body_size setting" is helpful. A paragraph of speculation about architecture is not.

Examples

Jira Bug Ticket Examples

See what good bug tickets look like. Use them as templates for your own.

By DropFile Editorial Team · Last updated April 11, 2026

A well-written bug ticket saves everyone time — the reporter, the developer picking it up, and the QA engineer verifying the fix. These examples show the structure and level of detail that makes tickets actionable. Each one follows a standard format: clear title, environment, reproduction steps, expected vs. actual behavior, and acceptance criteria.

API error on file upload

Users get a 500 error when uploading files larger than 10MB in the dashboard

**Title:** 500 error on file upload exceeding 10MB in dashboard

**Priority:** High | **Type:** Bug

**Environment:** Production, Chrome 124, macOS

**Steps to reproduce:**
1. Navigate to Dashboard → Documents
2. Click "Upload file"
3. Select any file larger than 10MB (e.g., a 12MB PDF)
4. Click "Upload"

**Expected:** File uploads successfully with progress indicator
**Actual:** Upload fails immediately with a generic 500 error. No file is saved. Console shows `413 Payload Too Large` from the API gateway.

**Acceptance criteria:**
- Files up to 25MB upload successfully
- Files exceeding the limit show a clear error message with the size limit
- Upload progress indicator works for large files

Specific reproduction steps, clear expected vs. actual behavior, and testable acceptance criteria. The console error detail helps developers skip the initial investigation.

Incorrect date formatting

Dates show as MM/DD/YYYY instead of DD/MM/YYYY for European users

**Title:** Date format shows US format (MM/DD/YYYY) for EU locale users

**Priority:** Medium | **Type:** Bug

**Environment:** Production, all browsers, EU locale accounts

**Steps to reproduce:**
1. Log in with an account set to "Europe/London" timezone and "en-GB" locale
2. Navigate to any page with dates (e.g., Activity Feed, Reports)
3. Observe the date format

**Expected:** Dates display as DD/MM/YYYY per the user's locale setting
**Actual:** All dates display as MM/DD/YYYY regardless of locale setting. The locale preference is saved correctly in user settings but not applied to date rendering.

**Acceptance criteria:**
- Dates respect the user's locale setting across all pages
- Supported formats: DD/MM/YYYY (EU), MM/DD/YYYY (US), YYYY-MM-DD (ISO)
- Existing date pickers also respect the locale

Locale bugs need specific locale and timezone details. The acceptance criteria cover the full scope — not just the fix but the expected behavior for all supported formats.

Search results not updating

Search results on the inventory page don't update when you clear the search field

**Title:** Inventory search results persist after clearing search field

**Priority:** Medium | **Type:** Bug

**Environment:** Production, Chrome & Firefox, desktop only

**Steps to reproduce:**
1. Navigate to Inventory → All Items
2. Type "widget" in the search field — results filter correctly
3. Select all text in the search field and delete it (or click the X to clear)
4. Observe the results list

**Expected:** Results return to showing all items when the search field is empty
**Actual:** Results remain filtered to the last search term. Only a full page refresh resets the list. The URL query parameter `?q=widget` also persists after clearing.

**Acceptance criteria:**
- Clearing the search field resets results to the full unfiltered list
- The URL query parameter is removed when search is cleared
- The clear button (X) and manual deletion both trigger the reset

This ticket identifies a state management bug and includes the URL parameter detail that helps developers find the root cause faster.

Tips

•Start the title with the symptom, not the cause. "500 error on file upload" is better than "Nginx proxy config wrong" — you might be wrong about the cause.
•Always include the environment: browser, OS, production vs. staging, and any relevant account settings (locale, role, plan tier).
•Acceptance criteria should be testable by QA without needing to read the description. Each criterion should be independently verifiable.
•Include what you've already checked. "Console shows 413 from API gateway" saves the developer from repeating your debugging.
•Attach screenshots or screen recordings for visual bugs. For API errors, include the request/response from the network tab.

Try it yourself

Open the Jira Ticket and generate your own results from a plain-English description.

Open Jira Ticket