Bug & Defect Triage Severity Log Markdown Table Template
A defect log in Markdown is a snapshot of your tracker taken for a specific conversation: the weekly bug scrub, a release sign-off report, or a customer-facing list of known issues. The tracker remains the source of truth; the table exists so that a release manager can read twenty defects on one screen and make a go/no-go call without clicking into each ticket.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
Severity and priority are separate judgements, and good triage keeps them apart. Severity describes technical impact — data loss, crash, wrong output, cosmetic — and is usually set by whoever reproduced the bug. Priority is a scheduling decision made by the product owner. A typo on the pricing page is low severity and high priority; a crash in a feature nobody has enabled may be the opposite. This template carries Severity only; add a Priority column if the meeting decides ordering.
The test of a good row is whether a developer who has never seen the ticket could reproduce the problem from the summary and the build number alone. “Export broken” fails that test. “LaTeX export aborts when a cell contains an unescaped %, on v1.9.8” passes it, and it also tells the reader which component owner to ping.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Defect ID | center :---: | The tracker key in backticks, centered, ideally linked to the ticket: `BUG-204`. Never renumber or reuse IDs between reports; people quote them in commits, chat, and changelogs long after the table is published. |
| Summary / Reproduction Case | left :--- | Symptom, condition, and environment in one line: what goes wrong, when, and where. Keep full numbered steps in the ticket; if they must appear here, separate them with <br>. Escape any literal pipe as \|, including inside code spans. |
| Severity | center :---: | One label from a fixed, defined scale such as Blocker / Critical / Major / Minor / Trivial, or S1–S4. Centered. Bold the top two levels so they stand out when the table is skimmed in a release meeting. |
| Component | left :--- | The module or area exactly as your tracker and code-ownership file name it, so each row can be routed to an owning team without discussion. Use the same spelling every time; “Grid Editor” and “grid-editor” fragment filters. |
| Observed Build | center :---: | The exact version or commit SHA on which the defect was reproduced, in backticks. For release reports, re-verify open bugs on the release candidate and update this cell, otherwise you are reporting against a build nobody ships. |
| Status | center :---: | A workflow state copied from the tracker (Open, Investigating, In Progress, Fixed, Verified, Won’t Fix). Centered. Keep Fixed (code merged) distinct from Verified (QA confirmed on a build); sign-off should count only the latter. |
How to Fill It In
- 1Export the defects from a saved tracker query rather than by hand — for example a JQL filter on
fixVersionandtype = Bug, orgh issue list --label bug --json number,title,statefor GitHub Issues. Convert a CSV export with CSV to Markdown. - 2Rewrite each summary into symptom-condition-environment form. Ticket titles written at filing time are often guesses about the cause (“race in worker pool”) rather than descriptions of what users see.
- 3Re-test every open defect on the current release candidate and update Observed Build. Close or mark “Cannot reproduce” anything that no longer occurs, with the build you tested.
- 4Check severities against your written definitions and challenge outliers in the meeting, not in comments afterwards. Severity inflation erodes the meaning of the column within a few releases.
- 5Sort by Severity, then Status. The classic Blocker → Trivial labels happen to sort correctly as plain text, but High / Medium / Low does not (it sorts High, Low, Medium), so use
S1–S4or a numeric helper column with the Markdown table sorter.
Ready-to-Paste Variations
Release sign-off with fix and verification builds
For the QA report attached to a release. Tracks where each defect was found, where it was fixed, and whether the fix has been confirmed on a build.
| Defect ID | Summary | Severity | Found In | Fixed In | Verified |
| :---: | :--- | :---: | :---: | :---: | :---: |
| `BUG-311` | CSV import drops the last row when the file has no trailing newline | **Critical** | `v3.2.0` | `v3.2.1` | Yes |
| `BUG-318` | Header row loses alignment colons after column reorder | Major | `v3.2.0` | `v3.2.1` | Yes |
| `BUG-322` | Tooltip overlaps the copy button at 320 px width | Minor | `v3.1.4` | — | No |Triage view with severity and priority
For a bug scrub where the group decides scheduling. Severity is set by QA before the meeting; priority, owner, and target are filled in during it.
| Defect ID | Summary | Severity | Priority | Owner | Target |
| :---: | :--- | :---: | :---: | :--- | :---: |
| `BUG-330` | Pricing page shows the old annual price | Minor | **P1** | @web-team | `v3.3.0` |
| `BUG-331` | Crash when the experimental pivot view is opened twice | **Critical** | P3 | @data-viz | Backlog |
| `BUG-334` | Session cookie not cleared on logout in Safari | Major | **P1** | @auth-team | `v3.2.2` |Known issues for release notes
Customer-facing version. Drop internal fields and give each issue a workaround, which is what readers of release notes actually need.
| Issue | Affects | Workaround |
| :--- | :---: | :--- |
| Large pastes (over 5,000 rows) freeze the preview for several seconds | `v3.2.x` | Paste in smaller blocks or use file import |
| Firefox does not show the “copied” confirmation | `v3.2.0`–`v3.2.1` | The content is still copied; paste to confirm |Common Mistakes
Using one field for both severity and priority, so a cosmetic bug on a high-traffic page gets labelled Critical.
Keep Severity for technical impact and add a separate Priority column for scheduling. The triage-view variation shows both side by side.
Counting “Fixed” defects as closed in a release sign-off.
Merged code is not a verified fix. Require a Verified status, or a Fixed In build that QA has tested, before a defect stops counting against the release.
Leaving the build or environment out of the row.
Always record the exact version or SHA, plus browser or OS when relevant. Without it, the first response to the bug is “cannot reproduce” and a day is lost.
Pasting raw error messages or stack traces that contain
|characters, which split the row into extra cells.Escape pipes as
\|(see escaping pipes) or, better, keep the trace in the ticket and summarise the symptom in the table.
Related Markdown Table Templates
Browse all 50 templatesPros & Cons Architectural Decision (ADR)
Evaluate technical tradeoffs, architectural decisions, library selections, and deployment approaches with balanced pros and cons.
Company & Team Quarterly OKRs Matrix
Objectives & Key Results governance table tracking strategic focus, baseline metrics, quarterly goals, confidence ratings, and leads.
Engineering Onboarding & Access Checklist
Structured onboarding milestone checklist for new software engineers covering hardware setup, repo permissions, local dev, and first deploy.
Bug & Defect Triage Severity Log: Frequently Asked Questions
What is the difference between bug severity and bug priority?
Severity measures how badly the defect affects the software: crash, data loss, incorrect result, or cosmetic. Priority measures how soon the team will fix it, which also depends on how many users see it, business deadlines, and available workarounds.
Is there a standard set of severity levels?
No single standard is universal. Four or five levels are common, such as Blocker, Critical, Major, Minor, and Trivial, or S1 to S4. What matters is that each level has a written definition with examples, so that different testers assign the same level to the same bug.
How do I link a defect ID to the ticket inside a Markdown table?
Use ordinary link syntax in the cell, and wrap the ID in backticks inside the link text if you want code styling: `BUG-204`. Links work in GFM table cells exactly as they do in paragraphs.
Should the release report list every bug or only open ones?
For a go/no-go decision, list every defect targeted at the release with its status, so readers can see what was fixed as well as what remains. Customer-facing release notes should list only open known issues with workarounds.