---
id: KB-PR-010
url: https://app.codecontract.io/help/troubleshooting/deciding-whether-a-problem-is-serious
idioma: en
categoria: problemas
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-PR-006, KB-PR-009]
citadoPor: [KB-PR-001]
---

# Deciding whether a problem is serious

_When it can wait until tomorrow and when to write immediately._

**Responde a:** is this urgent or can it wait · when should i contact support · what to do when something does not work · how serious is this issue

Not everything that fails is urgent, and treating everything as urgent means what genuinely is gets lost in the noise. The question that sorts it is simple: is someone outside waiting, or is money or a deadline involved?

## The three levels

| Level | How to recognise it | What to do |
| --- | --- | --- |
| Now | Affects third parties, a payment or a legal deadline | Write with the error code, without waiting to reproduce it |
| Today | Blocks you but does not leave the organisation | Rule out your own side first, then write |
| Whenever | Annoying but there is a way to carry on | Note it and group it with others |

## What is almost always "now"

- A send that went to the wrong person.
- A charge taken twice, or one that does not add up.
- A document visible to someone who should not see it.
- Anything blocking a signature on the last day of a deadline.

> [!IMPORTANT]
> If the fault exposed third parties' data to someone who should not see it, it is not merely a technical issue: tell whoever handles data protection that same day. There are duties with short deadlines and they start running from when you know.

> [!WARNING]
> Do not retry a failed payment or charge, not even "just to check". Report it with its code; retrying is how you end up with two charges instead of one.

## What to say, at any level

The error code if there was one, what you were trying to do in one sentence, and whether it happened once or repeatedly. That is enough: the code already carries what the system was doing.

> [!NOTE]
> If you hesitate between "today" and "whenever", check whether someone outside is waiting. That raises real urgency more than anything, even when it feels minor to you.

**Should I report it even if it was my mistake?**

Yes. Half of what gets reported ends up improving something for everyone.

**What if I cannot reproduce it?**

Report it anyway with the code: that is where what happened is recorded.

**Is there a status page?**

Yes, and it is the first thing to check if it works for nobody.

## Ejemplos

**Someone sees a charge taken twice and is about to retry the operation.**

- Stops
- Copies the error code
- Reports it as urgent

→ It is resolved with a single charge instead of three and a refund.

**A fault affects one person and there is a workaround.**

- Reports it and continues the other way

→ Work does not stop for something that can wait.

**A fault blocks a send due tomorrow.**

- Writes stating the deadline

→ The urgency is understood without having to insist.

**Something looks wrong but the data is right.**

- Checks whether it affects what is delivered

→ A display problem is told apart from a content one.

**A fault affects data going to a third party.**

- Treats it as urgent and raises it

→ It is stopped before something incorrect goes out.

**Every fault is escalated as critical.**

- Uses a written criterion to decide

→ Urgent things are handled sooner because they do not compete with everything else.