Bug Prioritization

Not all bugs are equal. Some stop customers from tracking data entirely. Some are minor cosmetic issues in the dashboard. We use a simple priority system to make sure critical issues get immediate attention and minor ones don't get lost.

Priority levels

P0 - Critical (fix now)

Data loss, tracking completely broken, or a customer's entire setup is non-functional.

Examples:

Events are not being received by Hardal servers
A server-side integration is sending corrupted data to a destination
A customer's first-party domain is returning 500 errors
The dashboard shows no data for a customer who has active tracking

Response: Drop everything. Fix or mitigate within hours. The person who discovers it owns it until it's resolved or handed off explicitly. Open a war room in Slack immediately. Post an update to the affected customer within 30 minutes.

P1 - High (fix this sprint)

A significant feature is broken or a customer-facing flow is impaired - but the core tracking still works.

Examples:

A destination integration is failing for a specific event type
The onboarding setup wizard errors out halfway through
Reports are showing delayed data (24h+ lag)
A specific customer's consent management layer isn't filtering correctly

Response: Fix within the current sprint. If discovered mid-sprint, it replaces something else - it doesn't go on the backlog.

P2 - Medium (next sprint)

A real bug, but with a workaround or limited impact.

Examples:

A dashboard filter returns incorrect results in edge cases
The API returns a confusing error message when auth fails
Email notifications are delayed but eventually send
A feature works correctly but the UI is misleading about what it's doing

Response: Goes into the next sprint planning. Documented clearly in Linear.

P3 - Low (backlog)

Minor issues, cosmetic problems, or edge cases that affect almost no one.

Examples:

Tooltip text is slightly wrong
A chart label overflows on very small screens
Documentation refers to an old UI element
A deprecated endpoint still works but returns a warning

Response: Logged in Linear with the P3 label. Reviewed during sprint planning. May never be fixed if more important work keeps coming in.

How to report a bug

When you find a bug or a customer reports one:

Reproduce it yourself if possible
Create a Linear issue with: what happened, what was expected, steps to reproduce, and any relevant logs or screenshots
Assign the correct priority level
If P0 or P1, notify the relevant engineer in Slack immediately - don't rely on Linear notifications alone

Customer-reported bugs

When a customer reports a bug:

Acknowledge it within the same business day
Give them a priority level and rough timeline
If it's P0 or P1, give them a more specific update within 24 hours
Close the loop when it's fixed

We don't leave customers wondering whether their bug report went anywhere.

Post-mortems

For P0 incidents, we do a brief post-mortem within one week. Not to assign blame - to understand what happened and prevent recurrence. Written in a Notion doc, shared with the team.

The format is simple: what happened, what we did, what we'll do differently.