Technical English guide
How to Explain a Bug in English
The vocabulary, sentence structures, and templates you need to explain bugs clearly in standups, tickets, Slack, and code reviews.
Bugs block the team. And unclear bug reports block the team even longer.
When you work on an international team, you need to explain a bug in English quickly and precisely. Whether it is a 15-second standup update, a Jira ticket, or a Slack message to a senior engineer, the words you choose matter.
This guide gives you the vocabulary and sentence structures to explain bugs like a professional.
The anatomy of a bug report
Partes de un buen reporte de bug
Every bug explanation has the same structure, whether you are saying it out loud or writing it in a ticket. If you include all five parts, your teammates can understand and fix the bug faster.
What you expected to happen
- "I expected the form to submit successfully."
- "The button should redirect the user to the dashboard."
- "I expected the API to return a 200 status."
What actually happened
- "Instead, the page returned a 500 error."
- "What actually happened is that the app crashed."
- "The user sees a blank screen instead of the results."
Steps to reproduce
- "To reproduce: log in as a regular user, go to Settings, and click Save."
- "You can reproduce this by opening the app on iOS 17 with a slow connection."
- "Steps to reproduce: 1) Add more than 10 items to the cart, 2) Click Checkout."
Environment / context
- "This happens on Chrome 124 on macOS."
- "I can reproduce it on the staging environment but not locally."
- "It only happens when the user is not logged in."
Severity / impact
- "This is blocking all users from checking out."
- "It affects around 10% of mobile users."
- "It is a visual issue and does not affect functionality."
Vocabulary: the words you need
El vocabulario que necesitas para hablar de bugs
These are the terms you will hear and use every week. Learn the definition and the example sentence. Then you will be ready.
| Term | Translation | Definition | Example |
|---|---|---|---|
| bug | error / fallo | An error in the code that causes unexpected behavior. | There is a bug in the login flow that prevents users from resetting their password. |
| defect | defecto | A flaw in the software that makes it behave incorrectly. More formal than 'bug'. | QA logged three defects in the latest release. |
| issue | problema / incidencia | A general term for a problem. Can be a bug, a task, or a feature request. | Can you have a look at this issue? It is affecting the checkout page. |
| regression | regresión | A bug that was not present before and appeared after a recent change. | The new deploy introduced a regression in the payment flow. |
| edge case | caso extremo / caso límite | An unusual situation that only happens under specific or rare conditions. | This bug only appears as an edge case when the user has no internet connection. |
| root cause | causa raíz | The original reason a bug exists, not just the visible symptom. | I found the root cause: the timeout was set to zero in the config. |
| workaround | solución temporal | A temporary fix that avoids the bug without solving it permanently. | There is a workaround: refresh the page after saving. |
| hotfix | hotfix / parche urgente | A quick fix deployed directly to production to resolve a critical bug. | We pushed a hotfix to production this morning. |
| reproducer | caso de reproducción | A minimal example or set of steps that reliably triggers the bug. | I built a reproducer — you can see the bug in three steps. |
| flaky test | test inestable | A test that sometimes passes and sometimes fails with no code change. | This CI failure is a flaky test, not a real bug. |
| stack trace | traza de pila / stack trace | The log showing which functions were called when an error occurred. | Can you share the stack trace? I need to see where the error originates. |
| deadlock | bloqueo mutuo / deadlock | A situation where two processes wait for each other and neither can proceed. | We have a deadlock in the database — two transactions are waiting on each other. |
| race condition | condición de carrera | A bug that depends on the timing of two processes running at the same time. | I am blocked because of a race condition in the notification service. |
| memory leak | fuga de memoria | A bug where the program keeps using memory but never releases it. | The app slows down over time because of a memory leak in the image loader. |
| off-by-one error | error de desplazamiento por uno | A bug caused by a loop or index starting or ending one position too early or too late. | There is an off-by-one error in the pagination — the last item is missing. |
Explaining a bug in a standup
Cómo explicar un bug en el standup
The standup is 15 minutes. You need to be clear and brief. These phrases give you a template to fill in with your own bug.
"I found a bug in the payment flow. It only happens when the user has an expired card."
State where the bug is and when it appears.
"I am blocked because of a race condition in the notification service."
Use 'blocked because of' to explain the reason clearly.
"I have a reproducer for the bug but I have not found the root cause yet."
This shows progress without overpromising a fix.
"I am investigating a regression that appeared after yesterday's deploy."
Use 'regression' when the bug appeared after a recent change.
"I fixed the bug from yesterday. It was an off-by-one error in the pagination."
When the bug is fixed, name what it was.
"There is a flaky test in CI. I am checking if it is a real bug or just the test."
Separate the flaky test from a real code problem.
"I found a memory leak in the image loader. It slows down the app after 10 minutes."
Include the visible impact so the team understands urgency.
"I need someone from the backend team to look at this. It might be a deadlock."
Ask for help specifically and name the type of issue.
Practice standup English:
Explaining a bug in a ticket or Slack
Cómo explicar un bug en un ticket o en Slack
Written bug reports need more detail than a standup update. Here is a full example of a GitHub issue or Jira ticket, with each part labeled.
Example ticket
Checkout button disabled when cart has more than 10 items
Summary
Checkout button disabled when cart has more than 10 items
Steps to reproduce
- Log in as a registered user.
- Add 11 or more items to the cart.
- Go to the cart page.
- Observe that the 'Checkout' button is disabled.
Expected behavior
The Checkout button should be enabled as long as the cart is not empty.
Actual behavior
The Checkout button is disabled and the user cannot complete the purchase.
Environment
Chrome 124 on macOS 14. Also reproduced on Firefox 125.
Severity
High — this blocks a significant portion of users from completing a purchase.
Explaining a bug to a non-technical person
Cómo explicar un bug a alguien no técnico
When you talk to a product manager, a stakeholder, or a customer, avoid technical jargon. Focus on what the user cannot do, not on what caused the code to fail.
Technical version
"There is a null pointer exception in the checkout service when the cart exceeds the item limit in the session object."
Plain English version
"The checkout button stops working when the cart has more than 10 items. Customers cannot complete their purchase."
Remove the cause. Keep the impact and the user action.
Technical version
"The authentication token is not being refreshed after the JWT expiry window, causing a 401 on subsequent API calls."
Plain English version
"Users get logged out unexpectedly after about an hour. They have to log in again to continue."
Replace the technical mechanism with what the user experiences.
Technical version
"There is a race condition between the payment callback and the order status update."
Plain English version
"Sometimes an order is marked as failed even though the payment went through. The customer is charged but cannot access their order."
Lead with the user impact, especially if it involves money.
Describing severity in English
Cómo describir la urgencia de un bug en inglés
Using the right severity language helps the team prioritize without drama. Here are common severity levels with example phrases.
Critical / P0
- "This is blocking all users from logging in. We need to fix this now."
- "Production is down. This is a P0."
- "This is a critical bug — it is causing data loss."
High / P1
- "This affects around 20% of users on mobile. We should fix it in this sprint."
- "This is a high-priority issue. It is blocking checkout for users with large carts."
- "I would classify this as P1 — it is not down but it is hurting conversions."
Medium / P2
- "This is a visual bug on the settings page. It does not affect functionality."
- "This is medium priority. It is inconvenient but there is a workaround."
- "It is P2 — we should fix it, but it is not blocking anything."
Low / P3
- "This is a minor typo in an error message. We can fix it when we have time."
- "Low priority — cosmetic only."
- "This is a P3. Nice to fix, but it is not urgent."
Learn more about blocking vs optional in code reviews:
Common mistakes when explaining bugs in English
Errores comunes al explicar bugs en inglés
These are mistakes many developers make when switching from Spanish to English. The fix is usually more specific language.
Avoid
"The bug is in the code."
Better
"There is a null reference bug in the CartService.checkout() method."
Too vague. Name the location and the type of bug.
Avoid
"It's not my bug."
Better
"This might be coming from the auth service, not our code."
'It is not my bug' sounds defensive. Point to the source instead.
Avoid
"I don't know why."
Better
"I have not found the root cause yet, but I am investigating."
Show that you are working on it. 'I do not know' with no follow-up sounds like giving up.
Avoid
"There is an error in production."
Better
"There is a bug in production that is preventing users from logging in."
'Error' can mean a compile error, a runtime exception, or a user error. Use 'bug' for unexpected behavior in working code.
Avoid
"The thing is broken."
Better
"The file upload feature is not working on Safari 17."
Name the specific feature and the environment where it breaks.
Keep practicing
Sigue practicando
Understanding the vocabulary is just the first step. Practice using these phrases until they come naturally.
Ready to practice your English at work?
Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.
Try Lingua-e for free
Written by
Roxana LafuenteLingua-e's founder
Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.