Bug Bounty Triage Metrics and SLAs That Actually Matter

You can't tell whether your triage is working by how it feels. It always feels fine from the inside, until you look at the numbers and discover your median first response is nine days and your best researcher hasn't submitted since March. Triage is an operational function, and operational functions get managed with metrics or they don't get managed at all.

Here are the six that matter, sensible targets for each, and how to instrument them without building a data platform.

The six metrics

1. Time to first response (TTFR)

The clock from report submission to the first human message the researcher receives. Autoresponders don't count, and researchers know the difference: "thank you for your submission" from a template buys you nothing.

This is the most visible metric in your program because it's the one researchers experience directly on every single report, valid or not. It's also the cheapest to fix, since a genuine first response ("read it, IDOR on the invoices endpoint looks plausible, reproducing now") takes minutes and doesn't require completing validation.

2. Time to triage (TTT)

Submission to verdict: valid, duplicate, informative, or not applicable, with reproduction actually performed for the valids, not rubber-stamped. This is the metric that measures whether triage capacity matches report volume. When TTT starts drifting upward week over week, you have a capacity problem, and it will not fix itself.

Track the median and the 90th percentile. Medians hide the handful of gnarly reports (the race conditions, the multi-step chains) that sit untouched for a month and generate your angriest researcher threads.

3. Duplicate rate

Duplicates as a share of total submissions. Some duplication is a healthy sign (multiple skilled people hunting the same fresh scope); a rate that's high and climbing usually means something specific: fixes shipping too slowly, known issues not documented in your policy, or one vulnerability class being rediscovered because the root cause was never addressed. A subdomain takeover reported six times points to one dangling DNS record you haven't cleaned up. More on handling this in our guide to duplicate reports.

4. Valid-report rate (signal rate)

Valid, unique, in-scope reports as a share of everything received. On public programs, 15–25% is a common neighborhood; private, invite-only programs run much higher. Watch the trend rather than the number: a falling signal rate means your policy is attracting noise: vague scope, no clear out-of-scope list, or a reputation for paying low-effort submissions. A rising rate with falling volume can be equally informative: your scope may simply be getting hunted out, which is a conversation about scope expansion.

5. Time to bounty (TTB)

Submission (or validation; pick one, define it, publish it) to money in the researcher's account. Researchers forgive a lot if payment is fast, and forgive very little if it isn't. Programs that award at triage rather than at fix consistently earn better researcher goodwill, and there's rarely a good reason to make a researcher wait months for your engineering backlog before being paid for work they finished in week one.

6. Retest turnaround

Fix-deployed to retest-complete. The forgotten metric. A slow retest loop means reports stay open for months, researchers can't disclose or claim resolved status, and, worse, broken fixes go undetected until a new researcher finds the same hole and you pay for it twice. If you don't track this one, it silently becomes "never."

SLA targets by program maturity

These are targets we consider both respectable and achievable (business days throughout). Plenty of programs publish tighter numbers than they hit; researchers screenshot the gap.

Two notes on using this table honestly:

• Publish only what you can hit at your worst week, not your best. An SLA you meet 95% of the time builds trust; one you meet 60% of the time is a standing complaint generator. Under-promise, over-deliver: nobody has ever rage-quit a program for being triaged faster than advertised.
• New programs should set conservative SLAs and tighten them publicly. Announcing improved SLAs six months in is good researcher relations. Quietly missing aggressive ones is the opposite.

How to instrument this

You don't need a data warehouse. You need timestamps and a spreadsheet, at minimum.

On the major platforms: HackerOne, Bugcrowd, Intigriti, and YesWeHack all expose response-efficiency metrics and APIs. Pull report events on a schedule and compute your own percentiles rather than relying solely on the platform dashboard. Platform "response" definitions don't always match what researchers experience (some clocks stop on any state change, including ones that aren't meaningful responses).

Self-hosted: capture five timestamps per report and you have everything above:

received_at, first_human_response_at, verdict_at, paid_at, retested_at

A weekly job that computes median and P90 for each interval, split by severity, is an afternoon of work and will tell you more about your program's health than any amount of gut feel.

Review cadence: look at the numbers weekly, act on trends monthly. The usual failure mode: someone builds the dashboard and nobody ever looks at it again.

One caution: don't turn any single number into a bonus target. A team paid on time-to-triage will hit it by closing borderline reports as informative: queue's empty, researchers are furious, metric looks great. Keep a human reading the numbers alongside the researcher-sentiment signal (comment tone, repeat-submitter rate) that doesn't fit in a percentile.

Why slow triage bleeds your best researchers first

Top researchers are running a portfolio. They have standing invitations to more private programs than they have evenings, and they allocate hunting time by expected value: bounty size × probability of fair treatment ÷ friction. Your response time is the friction term, and it's the first thing they learn about you: a researcher discovers your TTFR on their very first report, long before they discover how generous your criticals are.

So attrition runs in quality order. The researcher who can chain an SSRF into cloud credential theft has the most alternatives and leaves first, silently. The scanner-wrapper submitters have no alternatives and stay forever. Volume holds steady, signal rate slides, and eighteen months later someone asks why the program "only gets junk now." The junk was constant; the good half of the distribution left, one missed SLA at a time. The full damage math is in what a bug bounty program really costs.

The repair is unglamorous: consistent speed for a sustained period. Reputation damage takes months to accrue and longer to unwind, because the researchers you lost have to hear you've improved (usually from other researchers) before they'll spend an evening testing the claim.

If the numbers say you have a capacity problem

They usually do. That's typically why someone starts measuring. Rising TTT with steady volume means the queue is winning, and the options are the ones covered in in-house vs. outsourced triage: staff it, buy it from your platform, or bring in specialists. What doesn't work is asking the current team to be faster at a job they're doing in the margins of another job.

We're happy to be the capacity: TRIAGERS™ provides on-demand triage teams with same-day first response and per-report pricing, so your SLAs stop depending on whose sprint got interrupted. If your dashboard is telling you something you don't like, get in touch.