Priority Levels Explained

When you report an issue during UAT, you’ll give it a priority from 1 to 5. Priority tells us how urgent something is relative to your launch — it’s how we decide what to work on first when time and budget are finite. Setting priority thoughtfully is one of the most valuable things you can do during testing: it’s how we make sure the things that truly matter for your launch get handled first.

You set priority once, right in the Marker.io report form. It stays in sync with our project tracker automatically, so there’s nothing to enter twice and no other tool you need to open.

Two things to keep in mind before we get into the levels:

• Priority is about urgency and timing — not what kind of issue it is. A bug and an enhancement can each be any priority. (For the difference between bugs, enhancements, and discussions, see Issue Types.)
• Priority 3 is the default. Every new issue starts at P3, so part of your job is simply to move things up or down from there based on how much they affect your launch.

Priority 1 — Critical for launch

A true blocker. Something core is broken, or a user can’t complete an essential action — and the site should not go live until it’s resolved.

Examples:

• A key page won’t load, or the main navigation is broken.
• A form, login, or other essential action fails.
• Content is badly broken on a high-traffic page.

Priority 2 — Important for launch

Not a hard blocker, but you’d really prefer not to launch with it. A noticeable problem on an important page or feature that affects the experience without fully preventing it.

Priority 3 — Needed for launch (the default)

Should be addressed before or around launch, but wouldn’t stop the site from going live on its own. This is where most standard fixes and polish land — and it’s the starting point for every issue until you tell us otherwise.

Examples:

• A styling or layout detail that’s off but still usable.
• A feature that works as intended but could be a little cleaner.

Priority 4 — Nice to have for launch

A minor item we’d happily address if time and budget allow, but that’s perfectly fine to handle shortly after launch if we need to focus our energy elsewhere first.

Priority 5 — Post-launch

The lowest priority — and an important one to use. Enhancements, nice-to-haves, edge cases, and ideas for future iterations live here. Marking something P5 tells us “I want this on the record, but it absolutely should not hold up launch.” It’s a great way to park good ideas without crowding your launch.

Examples:

• An enhancement beyond the original project scope.
• An issue that only appears in an unusual, rarely-used scenario.

Choosing the right priority

The simplest way to set priority is to ask yourself one question:

What happens at launch if this isn’t fixed?

If the answer is “we genuinely can’t go live,” that’s a Priority 1. If it’s “I’d love this eventually, but it can wait,” that’s a Priority 5. Most things land somewhere in between — and that’s exactly right.

A quick, honest word on being realistic, because it makes a real difference to your launch:

• If everything is a Priority 1, nothing is. When every issue is marked critical, we lose the signal that tells us what truly can’t wait, and the genuinely launch-blocking items get harder to spot. Reserve Priority 1 for the things that would actually stop you from going live.
• If everything is a Priority 3, that’s usually a sign priority wasn’t considered. Since P3 is the default, a list that’s all 3s tells us the items were submitted without weighing their urgency. A thoughtful list almost always has a spread — a few criticals, a healthy middle, and some you’re glad to defer.

A realistic mix is the single most helpful thing you can give us. It lets us focus where it matters most to your launch — and that’s how we get you live on time, with the things that count working beautifully.

---

Related: Issue Types · UAT Overview