A Close Look at Unity User Reporting — What It Gives You and What It Doesn't

What Unity's official User Reporting package actually puts in a report, what it leaves out, and the ongoing shift from Cloud Diagnostics to the built-in Diagnostics service in Unity 6.2+ — sticking to confirmed facts only.

  • unity
  • bug-report
  • qa

Before building your own bug reporter, check whether Unity already gives you one. Unity ships an official package called User Reporting. This post lays out exactly what it provides and what it doesn't, staying within what's confirmed in the official documentation.

What User Reporting gives you

Drop it into a game under development and it collects bug reports and feedback from players. A single report carries:

FieldContent
BasicsTitle, description text
MetadataDevice information (DeviceUniqueIdentifier is excluded for PIPL compliance)
Events / metricsAnalytics-style data logged through LogEvent
ScreenshotsAutomatic capture
AttachmentsOptional additional files

You attach custom metadata via UserReportingService.Instance.AddMetadata and log events with LogEvent. A drag-and-drop example prefab for the report form ships alongside it. The docs also state that notifications can route to Slack, email, or Jira. Log a progress checkpoint through LogEvent every time a level is cleared, for instance, and a report that comes in later already tells you how far that player got, no extra question needed — the event log alone reconstructs it.

Documented performance impact is "mostly negligible," with the screenshot capture and upload being the exception — that adds data usage. When idle, the reporter holds no extra resources.

What User Reporting doesn't give you

The most important line first: there is no video capture. Nowhere in the official documentation is recording mentioned, and screenshots are the ceiling of what gets captured. If your goal is "see the last few seconds before the bug," this package alone doesn't get you there. Timing and physics bugs live or die on cause and effect across a few frames, and diagnosing them usually means seeing the seconds right before and after the moment it broke — a single screenshot never carries that context to begin with.

There's also no documented equivalent of a rolling log buffer that automatically attaches the last N console lines. LogEvent is closer to analytics events you call explicitly, a different layer from automatically hooking Application.logMessageReceived.

It's mid-transition, and you should know that going in

The parent service User Reporting sits under — Cloud Diagnostics — is itself deprecated and will be phased out over future Unity versions. Crash and Exception Reporting has already moved to the built-in Diagnostics service in Unity 6.2 and later, and User Reporting has been split out into its own package — the current identifier is com.unity.services.user-reporting, while the com.unity.cloud.userreporting you'll find in older material is the legacy name. Existing Cloud Diagnostics data is retained for only 7 or 90 days depending on your plan, so if you're setting this up fresh, figure out which Unity version baseline you're targeting first.

When it's enough, and when it isn't

SituationVerdict
Collecting feedback from internal testers during developmentEnough — drop in the form prefab and go
UI/text bugs reproducible from a description plus a screenshotEnough
Tickets repeatedly get closed as "can't reproduce"Not enough — you need video and richer game state
Timing, physics, or networking bugs where the moment mattersNot enough — a single screenshot can't catch it
Planning to run this long-term past the Cloud Diagnostics phase-outConfirm 6.2+ Diagnostics compatibility first

One question cuts through the whole table: can a text description plus one screenshot fully convey the conditions that reproduce the bug? If yes, User Reporting is enough on its own. If the bug only makes sense once you can see the exact timing of the moment, you've already stepped past what this package captures.

Summary

Unity User Reporting handles metadata, events, screenshots, and attachments for free. It stops there not out of neglect — video was never in scope. Once you need video, the next set of options is in the recording method comparison, and a minimal DIY setup for logs and state is in the minimal capture guide. The full map of decisions behind building a reporter is in part 1.

Our own Rekon picks up exactly where User Reporting stops — video on the same timeline as logs and state. If the official package covers your project, we'd say stick with it.