Bug, Defect, Issue, or Incident?

"Checkout is broken" is enough to start looking, but it doesn't tell us whether there's a confirmed defect, an unanswered question, or an incident in progress. Those labels should help people decide what to do next.

Bug and Defect Usually Cover Much the Same Ground

I'd normally treat bug and defect as interchangeable unless the team has documented a distinction. "Bug" tends to sound less formal. "Defect" often appears in testing, assurance, and contractual processes.

A particular organisation might reserve one term for a fault found before release and the other for one found afterwards. That is a local convention, not a rule you can safely assume another team shares.

Start with what differs from the intended behaviour. Perhaps a calculation rounds incorrectly, a keyboard user cannot reach a control, or an installation instruction omits a required step. A defect needn't be a mistyped line of application code.

The software might even work exactly as specified, with an incomplete or wrong specification behind it. Distinguish that from an implementation fault, but don't use "works as specified" to dismiss the user's problem.

An Issue Tracks the Work

GitHub's 2011 introduction to Issues 2.0 describes a place to organise, assign, and discuss work. A tracker can hold bug reports, feature requests, or documentation tasks. An issue asking for a clearer example needn't imply that the existing documentation is wrong.

A new issue may contain an observation which nobody has reproduced yet. It might turn out to be a defect, an unsupported configuration, a duplicate report, or a request for different behaviour. Creating the record doesn't settle the diagnosis.

"We closed twenty issues" doesn't mean twenty bugs were fixed. Some may have been questions, duplicates, or changes in scope. I'd check what was actually closed before treating that number as a measure of software quality.

An Incident Needs a Response

Google's SRE guidance on managing incidents emphasises establishing a coordinated response and restoring service. It also recommends clear conditions for declaring an incident. Each organisation needs conditions that fit its service. There isn't a universal number of affected users which turns a bug into an incident.

You can have an incident before you know whether a software defect caused it. An unavailable supplier, an expired certificate, or an accidental configuration change can all disrupt a service. Waiting for a confirmed code‑level explanation would delay the response.

A serious defect can need urgent work before it has caused an incident.

The Next.js production triage guide covers deciding what is affected and choosing a safe mitigation.

Link the Records; Don't Collapse Them into One

Disabling a broken promotion can contain a checkout incident without fixing the underlying calculation defect. The incident can end whilst the defect still needs a permanent correction. Follow‑up issues might cover the fix, missing test coverage, and clearer monitoring. Conversely, one incident can expose several defects, and one unresolved defect can contribute to more than one incident.

I'd keep those records linked, with separate owners and completion criteria where needed. "Incident resolved" should explain what has been restored. "Bug fixed" should identify the corrected behaviour and how it was checked. Closing one shouldn't silently close the other.

Severity and priority also deserve their own fields. Severity describes impact under the team's scheme; priority determines the order or urgency of work. A prominent spelling mistake and a rarely triggered calculation error can pull those judgements in different directions.

Whatever the ticket is called, record what happened, what should have happened, where it happened, and the evidence you have. Say what you don't yet know.