Triage bugs across platforms
Almost nobody files a good bug report. They post "anyone else getting booted back to the menu?" in a Discord thread at 2am, leave a one-star review that says "unplayable now", and complain on Reddit without ever naming the version they're on.
So the hard part of bug triage usually isn't fixing things. It's three other problems:
- The same bug wears fifty different costumes. One crash gets described in fifty ways, across four platforms, in six languages.
- Loud is not the same as widespread. A furious Steam thread with 200 replies might be forty people. A quiet trickle of Discord messages might be your entire Android install base.
- Old news keeps resurfacing. Something you patched two months ago is still being posted about, and it looks identical to a live issue.
This playbook is a routine that handles all three. It takes about twenty minutes a week once you've done it once.
Before you start
Connect at least two sources — ideally three. This isn't a nice-to-have for bug triage; it's the entire mechanism. Cross-source spread is the single clearest signal that a bug is real and widespread rather than one unlucky person with a bad driver.
If you only connect one source, you can find bugs, but you can't weigh them.
See Sources for the full list, and Integrations for setup.
1. Sweep for what's breaking
Start wide. Don't name a bug — you're trying to find the ones you don't already know about.
What are people reporting as broken or not working across all our connected sources in the last 7 days? Group them by theme and tell me which themes show up on more than one platform.
Two things make this query work. It asks for grouping, so you get themes instead of a wall of individual messages. And it asks which show up on more than one platform, which does your first pass of prioritization for you.
Run this on a fixed day each week. Bug triage gets dramatically easier when you're comparing against last week's list instead of starting cold every time.
2. Separate new from already-known
The sweep will resurface things you've already fixed. Cut those out by naming your current version explicitly:
We shipped 2.4 on Tuesday. Of the issues reported since then, which ones were NOT being reported in the two weeks before 2.4? I'm trying to find regressions introduced by the patch.
This is one of Kinn's real advantages, and it's easy to miss. Because Kinn answers from your own sources with real timestamps — rather than from the open web — it won't drag a viral thread from last year into a question about this week. Naming the version and window makes that precision work for you.
3. Measure how widespread it actually is
You've got a candidate. Now the important question, and the one teams most often skip: how many people, out of how many?
How widespread is the save-corruption issue? Look across Discord, Steam and Reddit for the last 30 days. Break it down by platform, and tell me what share of the feedback in each source mentions it.
A question shaped like this gets handed to Kinn's research agent rather than answered directly — it collects the full matching set, classifies each record, and calculates the counts deterministically. Crucially, it reports a separate denominator for each source, so a bug that's 12% of your Steam reviews but 0.5% of Discord reads honestly instead of being blended into one misleading average.
See Deep research for how this works and how to read the output.
4. Read the platform bias
Every source skews, and knowing how is most of the skill here:
- Steam skews toward strong reactions — anger arrives here first and loudest.
- Discord is your invested core — they'll tolerate more, and report in more detail.
- Reddit is comparatively detached and more willing to say "works fine for me."
- Stores (App Store, Google Play) surface device- and OS-specific problems that never show up elsewhere.
- Social (YouTube, TikTok, Instagram) is casual and creator-driven — good for reach, poor for detail.
A bug in Steam reviews and Discord and the stores is a real, broad problem. A bug that only exists in Steam reviews is often a specific hardware or configuration slice — still worth fixing, but not the emergency the volume suggests.
The crash on startup — is it showing up everywhere, or concentrated in one place? If it's concentrated, what do the people reporting it have in common?
That second sentence is the one that finds "it's only Steam Deck" or "it's only since the Android 15 update."
5. Get it into your tracker
Once something's worth acting on, hand it off rather than retyping it:
Write up the save-corruption issue as a bug report — what happens, how many people reported it, which platforms, first and last seen, and three representative quotes with links.
With a tracker connected, Kinn can go further and file it for you — searching first so you don't create a duplicate:
Does this match an open issue in our tracker? If not, create a Bug in the GAME project with a summary, affected platforms, and links to the supporting feedback.
Kinn only creates or changes issues when you ask, and it needs the Editor role or higher. It files into Jira and Linear; see also Bug detection & triage.
If you have Sentry connected, check it before you file. Sentry is read-only in Kinn — nothing gets written there — but pairing a community report against the error your telemetry actually recorded turns a vague ticket into one an engineer can act on, complete with a stack trace and a count of affected users.
6. Make it repeatable
The whole routine above can run on a schedule, so triage starts from a prepared list instead of a blank box:
Every Monday at 9am: sweep all sources for newly reported issues from the past week, group them by theme, flag anything appearing on more than one platform, and note anything that wasn't in last week's report.
See Scheduled tasks to set this up — that page also covers how to write a prompt that works unattended, which is a different skill from asking a good question in chat.
Common mistakes
Asking "what are the bugs?" with no window or version. You'll get a blend of live issues and things you fixed last quarter. Always name a timeframe, and name your current version when you can.
Treating one loud thread as prevalence. A 200-reply Steam thread feels like a crisis. Ask for the share of feedback it represents before you reprioritize a sprint around it.
Forgetting your non-English community. Kinn's search finds paraphrases and matches across languages, so a bug reported only in German or Portuguese will still surface — but only if you don't accidentally narrow the question to English phrasing. Describe the problem, not the exact words you expect.
Stopping at the first answer. A good triage session is a short conversation. Follow up: "of those, which are new?", "what do the reporters have in common?", "show me the three most detailed reports."
Next
- Deep research — how Kinn measures prevalence, and how to read the limits it reports.
- Size how widespread something is — going deeper on step 3 when the number has to hold up.
- Kinn for QA teams — where this playbook fits in a QA week.
- Bug detection & triage — how Kinn flags likely bug reports in the first place.
- Writing good queries — the habits behind the queries above.