Bug Triage Is a Full-Time Job You Can't Afford to Hire For

You don't have a QA hire. You don't have a triage lead. You have a Linear board, a Slack channel called `#bugs`, a Gmail inbox someone forwards from support@, and an Intercom that pings at 2am from Singapore.

Somewhere in there, every morning, a senior engineer drinks coffee and does a job nobody named.

The job nobody put on the org chart

Look at your org chart. There's an engineering lead. Two or three senior engineers. A junior. Maybe a designer who codes. Maybe a founder who still ships PRs on weekends.

There is no "Bug Triage Engineer." There is no role called "Inbox Sorter." There's nothing on the chart that says "person who reads 80 messages a day and decides which ones are real."

But that job exists. It exists every morning. It exists because users hit bugs and report them in seven different places using fourteen different wordings, and somebody has to read all of it, figure out what's actually broken, and turn it into a ticket your team can act on.

At five engineers, this is a 60-minute task. Your most senior person does it with coffee. They skim Intercom, glance at Slack, open three emails, and write four Linear tickets. Done by 9:30am.

At twelve engineers, that hour becomes four. It gets distributed across whoever happens to have a light morning. Sometimes that's your staff eng. Sometimes it's the new senior who started six weeks ago and doesn't yet know that the "page won't load" report from Tuesday is the same as the "blank dashboard" report from today.

At twenty engineers, it's a full-time job. Except nobody has it as their full-time job. So it remains four people's quarter-time job, done badly, in the cracks between actual shipping work.

This post is about what's inside that job, what it costs you, and what should be automated before it eats a third of your senior team's mornings.

What triage actually contains

People say "triage" like it's one thing. It's four.

Deduplication

The same bug shows up under four wordings in two hours.

• User A in Intercom: "The export button doesn't work."
• User B in support email: "I clicked Download CSV and got a 500."
• User C in Slack: "csv export broken since friday???"
• User D in your in-app feedback widget: "tried to get my data out, nothing happened"

Four reports. One bug. If you don't dedupe, you file four tickets. Your engineer picks up the first one, fixes it, marks it done. Three other tickets sit open. They get re-pinged when users follow up. Now you're answering "we already fixed this" emails for a week.

Dedup is pattern recognition across messy natural language. It is exactly the kind of work humans are bad at when they're tired and have eighty other tabs open.

Categorization

Not every report is a bug. You have:

• Bug: something broke that used to work
• Feature request: something they want that never existed
• Confusion: the thing works but they can't find it
• Billing: usually an Intercom message that should never have left the support tool

Confusion is the trickiest. "I can't invite my team" might be a bug (invite link is 500ing) or it might be confusion (the invite button is in Settings, not on the team page, and your UX is genuinely bad). Same words. Different fix. Different owner.

Miscategorize and you waste an engineer's afternoon trying to reproduce a bug that doesn't exist.

Severity scoring

Severity is frequency times user impact, roughly.

• One user reports the export button is broken. Severity: who knows. Could be their browser.
• Eight users report it in six hours. Severity: drop everything.
• Your biggest customer reports it once. Severity: drop everything, but quieter.

Severity is not "how bad does the bug feel." It's "how much pain does it generate, distributed across your user base, weighted by who's hitting it." That requires context: who is this user, how much do they pay, is this their tenth ticket this week.

Your junior engineer can't reliably do this yet. They will mark the senior customer's polite complaint as P3 because the user used the word "minor." They will mark the angry-but-non-paying user as P0 because the message had three exclamation marks.

Routing

Who owns it? Where does it get filed? What template? What labels? Does it need a customer-facing reply? Does the founder need to know?

At five engineers, routing is trivial. At fifteen, your codebase has owners. The auth bug goes to the auth team. The billing bug goes to whoever last touched Stripe. The CSV export bug goes to data infra. Get this wrong and the ticket sits in the wrong queue for three days.

Routing also includes writing the actual GitHub or Linear issue. With repro steps. With the user's email so you can reply. With the right labels so it shows up in the right view. That's a five-minute task per ticket if you're fast. Multiply.

The hidden cost: 30–50% of your senior eng's morning

Let's do the math.

A senior engineer at a post-PMF SaaS company costs you, fully loaded, around $200k–$280k a year. That's roughly $100–$140 an hour.

Now count tickets. A small B2B SaaS with 500 paying customers generates somewhere between 30 and 80 inbound signals a day across all channels. Most are not bugs. But all of them have to be read by someone to figure out which ones are.

At three minutes per signal to read, classify, dedupe-check, and decide if it needs a ticket, that's 90–240 minutes a day. Call it two hours for a mid-sized team.

Two hours. Every day. Of senior engineering time. At $120 an hour. That's $240 a day. $1,200 a week. Roughly $60,000 a year.

You are paying a hidden $60k salary to a job that does not exist on your org chart. And you're not getting $60k of value, because that work is being done by someone whose actual job is to ship features and architect systems.

The reason it has to be a senior is that severity judgment requires context. A junior can dedupe. A junior can mostly categorize. A junior cannot reliably look at "checkout flow hangs for some Stripe customers" and decide whether it's P0 or P2 without knowing what your last Stripe migration touched.

The reason it has to be morning is that if it slips, the day burns. Tickets pile up. Engineers start their actual work without a clear picture of what's broken in prod. By 3pm, a real P0 has been sitting in the queue for six hours and you find out from Twitter.

Why triage breaks at the 10-engineer mark

There's a specific point in team growth where triage stops working.

Up to about seven or eight engineers, triage is a solved problem. Your CTO or staff eng does it. They have the full picture of the codebase. They know every customer by name. They can hold the entire bug graph in their head.

Past ten, three things break at once.

Throughput exceeds judgment time. You can't read 80 signals in a morning and still have the cognitive bandwidth left to design systems. The senior eng either does triage badly or does their actual job badly. Usually both, alternately.

Errors compound. Missed duplicates become re-opened tickets. Mis-categorized bugs become engineers chasing ghosts. Mis-routed tickets sit in the wrong queue. Each error generates two more downstream — a user follow-up, an engineer asking "wait, didn't we fix this last week?"

Context-switch cost destroys shipping velocity. Even if triage only "takes" two hours, it costs four. You break flow. You re-enter the deep-work tab three times. The 4pm energy crash hits at 1pm.

This is the moment most teams hire a QA engineer or a support engineer to take the load. That's a $130k+ hire, plus benefits, plus six months of ramp. For a team of twelve, that's a meaningful budget line. For a team of fifteen at $1.5M ARR, it's a real decision: hire QA or hire another product engineer?

The answer is usually neither. The answer is usually "we'll figure it out." And the senior keeps eating the cost. See more on this dynamic in QA without a QA team.

The four parts of triage that should be automated

Map back to the four parts. For each: what software should do, what humans still own.

Automating deduplication

This one is mostly solved, technically. Semantic embeddings cluster natural-language reports by meaning, not by keyword. "Export button doesn't work" and "CSV download returns 500" live next to each other in vector space, even though they share zero significant words.

The threshold matters. Too tight, you miss dupes. Too loose, you cluster real distinct bugs together. Around 0.55 cosine similarity is a reasonable starting point for English support text, though it varies by source. We wrote about this in detail in clustering duplicate bug reports with embeddings.

What stays human: confirming the edge clusters. When the system says "these four messages are 71% similar," somebody has to glance at it and confirm yes-or-no. That glance takes three seconds. Multiply by the dozen clusters you generate a day and you're at 36 seconds of human review instead of 30 minutes of human reading.

Automating categorization

LLM classification is good enough for first-pass categorization. Bug vs feature vs confusion vs billing is a clean four-way classifier. Modern models hit 92%+ on this with a decent prompt and three examples per category.

What stays human: the confusing cases. "I want to bulk-archive issues" — is that a feature request or a confusion (because bulk-archive exists, it's just hidden in a right-click)? The classifier guesses feature. A human knows. So the system suggests, the human overrides when wrong, and the model gets better.

Automating severity scoring

This is the dangerous one. Severity requires context the LLM doesn't have — your business model, who pays you, what's in flight.

A reasonable middle ground: the system suggests severity based on frequency (how many users hit this cluster in the last 24h) and signal weight (paying user vs trial vs anonymous). The human approves or bumps it. Over time, the suggestions get better as the model learns your team's patterns.

What stays human: anything involving a named customer relationship. The system can flag "User X (top 10 ARR) reported this." It cannot decide whether to bump it to P0 because you owe them a favor from last quarter.

Automating routing

Routing is mostly rules: file in Linear, label `bug`, assign to the team that owns the touched code path. The hard part is "which team owns the touched code path," which an agent can guess from the bug description plus your CODEOWNERS file.

What stays human: the final accept. Before a ticket lands in your team's actual queue, a human glances and clicks Approve. Five seconds. Done.

This is also where reproduction matters. A triaged ticket without repro steps is half-useful. After triage comes the "can't reproduce" problem.

Where humans still belong

Don't oversell this. Triage isn't going fully automatic any time soon, and you don't want it to.

Humans still own:

• Edge-case severity. The system is right 90% of the time and dangerously wrong 10%. You want eyes on the suggestions.
• Customer relationships. When the report comes from a real human you've emailed before, the response is not a ticket. It's a reply. Software can flag it. A person writes it.
• Pattern recognition across weeks. "This is the third Stripe issue this month" is a human-noticed pattern. The system can help, but a senior eng connecting dots across long windows is still where strategy comes from.
• The judgment call on "is this a bug or is this how we want it to work." Sometimes the answer is "it's working as designed, but we should redesign it." That's a product call.

The goal isn't to remove the human. It's to remove the part where the human reads 80 messages to find the 12 that matter.

A realistic example

Here's what a triaged ticket should look like, after dedup, categorization, severity, and routing.

``` Title: CSV export returns 500 for workspaces > 10k rows Category: Bug Severity: P1 (8 reports / 6 hours, 2 paying users affected) Cluster: 4 user reports merged Source: 2 Intercom, 1 Gmail, 1 Slack Suggested owner: data-infra Repro: Tested in staging — confirmed 500 on workspace with 12,400 rows Affected users: alice@acme.com, bob@startup.io, +2 anon Filed: linear.app/team/issue/ENG-1847 ```

Before automated dedup, this was four separate tickets in four tools. The senior eng who triaged it spent twelve minutes reading the four reports, cross-referencing them, writing the Linear ticket, replying to alice@acme.com, and tagging the right team.

After: one cluster, one ticket, one notification, one human five-second approval. Same outcome. Twelve minutes back.

Do that fifteen times a day and you've recovered three hours of senior engineering time. Across a year, that's roughly 700 hours, or $85,000 in saved opportunity cost — assuming your senior eng spends those recovered hours shipping anything useful, which they will.

What this looks like with FixFirstly

The whole point of FixFirstly is that the four parts of triage that should be automated, are.

You connect Gmail, Slack, Intercom, Zendesk, your CSV exports, or pipe in via our API. Every signal lands in one place.

The agent clusters duplicates via semantic embeddings. It categorizes — bug, feature, confusion, billing. It suggests severity based on frequency and user weight. It drafts the GitHub or Linear issue with repro steps it actually verified against your staging environment, using a scoped test account with encrypted credentials and a full audit trail.

You get the final approval. Click accept, the ticket files. Click reject, the agent learns.

What used to be two hours of senior eng morning becomes ten minutes of approving the agent's suggestions over coffee. See how it works for the actual flow.

The free tier is genuinely free — $0/mo, no card, enough to triage a small team's inbound.

The statement

Bug triage is not a glamorous job. It is not on your org chart. It is not in anyone's job description. And it is eating a quarter to half of your senior engineering team's mornings, every single day, while costing you the equivalent of a junior hire in lost shipping velocity.

You can keep paying that hidden salary. Or you can automate the four parts of triage that should never have been human work in the first place, and give your senior engineers their mornings back.

Free tier. No card. Get on the waitlist.