Error Monitoring and QA Capture Solve Different Problems

"We already have Sentry — do we still need a QA capture tool?" comes up a lot. The answer depends on what your Sentry setup collects today and how QA reports bugs that leave no exception. This post separates the tools' primary jobs and the evidence each workflow needs.

What error monitoring solves

Sentry-style error monitoring collects and aggregates exceptions and crashes during runtime. Stack traces, frequency, affected user count, and per-release regressions are the core output. Sentry's Unity SDK focuses on exception and crash events, with breadcrumbs and device context. Screenshots can also be attached to events, but recording an anomaly QA notices during normal execution requires a separate trigger and evidence collection workflow. Say a crash rate spikes right after a release ships — the dashboard lets you filter to that release and see how many users were affected. (Sentry event attachments)

What QA capture solves

QA capture solves a different problem: handing off something a person witnessed during development, with evidence attached. What got witnessed need not be an exception. Broken UI, off balance numbers, a character clipping through a wall — these may leave no stack trace, and the game keeps running. Say a QA tester notices a character's animation stutter by two frames during a specific sequence. With only exception monitoring enabled, that observation does not become a bug report automatically. The Sentry Unity SDK can also receive manually submitted feedback, but someone still needs to provide a way for testers to flag the anomaly and collect reproduction evidence. (Sentry Unity SDK release)

Many game bugs leave no exception

Many game QA reports concern a state problem, not an exception — physics going haywire, script event ordering breaking, an art asset placed wrong. Without checks for a game's expected behavior, exception detection alone has little to work with. A person may need to judge the video and game state together. In manual playtesting, recording the gap a tester notices and passing it to someone else is especially important.

Why the confusion keeps happening

Both categories collect evidence about bugs, so their dashboards can look similar, but different signals start collection. Once a team gets used to an error-monitoring dashboard, it's easy to start reading "nothing showing up" as "nothing's wrong." A quiet Sentry dashboard doesn't make the UI bug QA found yesterday disappear. It's easy to see "zero crash reports" and conclude the build is stable, while QA has already filed several UI bugs on that exact build separately — two signals saying different things, with only one of them actually being checked.

Complements, not substitutes

Error monitoring auto-aggregates exception trends; QA capture attaches reproduction evidence to anomalies a person flags. Teams can add user feedback or game-specific events to Sentry to build a QA reporting flow. Even then, they need to decide how testers flag an issue and whether to collect video and game state. Teams can also use Sentry for exception trends alongside a QA capture tool for non-exception bugs. If the same person watches both, it helps to distinguish automatically collected exceptions from anomalies a person witnessed. The full category landscape is laid out in Unity Bug Reporting Tools Compared.

Summary

Even if a team uses error monitoring, it should check whether QA can hand off non-exception bugs with enough evidence. Ask whether the bugs being missed leave a stack trace; if not, find out what a tester records and where it goes. A team already using Sentry can decide whether to extend its feedback workflow or add a capture tool based on the evidence it needs.

Rekon collects evidence for QA capture — a Unity 2022.3+ plugin that, on one hotkey (Ctrl/Cmd + Shift + B) in Play Mode, captures roughly the last 60 seconds of video, logs, and game state (scene, device info) on one timeline, then connects to a Jira issue from the dashboard. It's built to hand off bugs that leave no stack trace with evidence attached, and can be used alongside error monitoring.