Logging bugs is only half the problem. Deciding which ones matter is the other half

We spent a lot of time learning how to log bugs properly.

Capturing context.

Reconstructing sessions.

Actually understanding what happened.

That part is hard.

But once you solve it, a different problem shows up:

Now you have too many bugs.

The real problem

Not every bug deserves to be fixed first.

But most teams don’t have a clear way to decide that.

So what happens instead?

They fix whatever is loudest.

What we started using

We moved away from intuition and looked at a few simple signals:

• Frequency — how often it happens

• Affected users — how many people it hits

• Critical flow — where it happens (login, payment, core actions)

• Latency / degradation — things that “work” but feel broken

• Error signal — clear failure vs silent issue

Even a simple combination of these changes how you prioritize.

But something still feels missing.

Some of the worst issues we’ve seen:

• no error

• low frequency

• everything looks fine

…but the outcome is still wrong.

That’s where this breaks.

Maybe severity isn’t just about errors.

It’s about whether the intended outcome actually happened.

Curious how others handle this.

How do you decide what’s worth fixing first?

Do you rely on data, or mostly intuition?