Skip to main content

🏷️ Set Ticket Priorities Using P0–P5 Tags (Internal GitLab SOP)

Use standard priority tags (P0 to P5) in GitLab to ensure consistent triage, response times, and SLA alignment.

Camilo Aponte avatar
Written by Camilo Aponte
Updated over a month ago

Setting the right priority level for GitLab issues ensures that our Product and DevOps teams respond with the appropriate urgency based on the impact to users and the business. This SOP outlines how to use P0–P5 tags to classify bugs, incidents, requests, and other internal issues effectively. By tagging issues accurately at creation time, we streamline triage, improve SLA tracking, and ensure critical blockers are never delayed.

🔍 What to do

When creating any issue in GitLab—whether it's a bug, incident, user report, or feature request—assign a priority tag (P0–P5) to reflect its severity, urgency, and business impact.

🌟 Why it matters

Prioritization tags guide how quickly teams respond and what resources get allocated. Using them correctly prevents overload, aligns with SLAs, and ensures critical issues are addressed first.

🛠️ How to do it


1. Create the issue in GitLab with full context: what broke, who’s affected, and how.

2. Apply the correct priority tag from P0 to P5 based on the impact.

3. Use the reference table below to determine triage urgency and SLA target.

4. Add justification and examples if the issue requires special escalation.

5. If uncertain, start with P3 and update the tag after review.

🧩 How to assign the right priority tag

✅ Use P0 when:

  • The entire platform or core service is unavailable

  • No users can access or perform essential tasks
    ​🔥 Examples:

    • No one can log in

    • Frontend or API completely down

✅ Use P1 when:

  • A major feature is broken or blocking large workflows

  • It's urgent, but not a total outage
    ​🔥 Examples:

    • Content Genius can’t generate articles

    • OTTO cannot deploy to production

✅ Use P2 when:

  • A key feature is broken for some users

  • Workarounds exist but are painful
    ​🔥 Examples:

    • Heatmaps stuck in fetching

    • Reports fail for specific clients only

✅ Use P3 when:

  • Issue is minor, non-blocking, or affects few users
    ​🔥 Examples:

    • Occasional API timeout

    • UI bug that doesn’t stop use

✅ Use P4 when:

  • Cosmetic, language, or layout issues
    ​🔥 Examples:

    • Misspelled label

    • UI misalignment in a menu

✅ Use P5 when:

  • Feature request or product suggestion
    ​🔥 Examples:

    • Change button color

    • Request for non-critical product tweak

📊 Priority Tag Reference Table

✅ Once done

Each issue will be correctly prioritized and visible to the right team (Product or DevOps), ensuring appropriate triage, response times, and SLA tracking. This enables faster resolution and better alignment with business impact.

🛑 Internal Use Only

This SOP is for internal use only and must not be referenced or shared in any customer-facing channels.

Did this answer your question?