Quick answer: Unity has deprecated Cloud Diagnostics. In Unity 6.2 and later, a built-in Diagnostics service replaces its crash and exception reporting and debugging symbols; User Reporting is not deprecated and continues as a separate package. Live games on legacy Cloud Diagnostics keep reporting for now, but there is no published sunset date. If you can upgrade to 6.2, Unity's Diagnostics is the obvious choice. If you are pinned to Unity 2020.3 through 6.1, or want player reports, Steam reviews and a tracker in the same place, an engine-agnostic tool such as Bugnet is the safer bet.
Cloud Diagnostics was the zero-effort crash reporter for a generation of Unity games: tick a box in the Services window and exceptions started showing up in the dashboard. Unity is now phasing it out. The replacement is good, but it comes with a condition many studios cannot meet mid-production: upgrading to Unity 6.2. Here is what Unity has actually announced, what it means for a shipped game, and how to choose between upgrading, switching and combining.
What Unity has announced
- Cloud Diagnostics is deprecated and will be phased out in future versions of Unity.
- Diagnostics replaces it in Unity 6.2 and later, covering crash and exception reporting and debugging symbols. The new service adds Application Not Responding (ANR) reports for Android 11 and later and more device and stability data.
- Live games keep reporting. Unity has said there will be no interruption for live games using legacy Cloud Diagnostics crash reporting while projects migrate, with client data proxied through to the new service.
- No sunset date yet. Unity has said it will fully remove the legacy package and service once most projects have moved, and promised a more detailed timeline later.
- Old data does not last. Cloud Diagnostics keeps data for 7 or 90 days depending on your Unity plan, so download any reports you want to keep as JSON.
- User Reporting is not deprecated. It continues as a standalone package that works with Diagnostics in Unity 6.2 and later.
The practical upshot: nothing breaks today, but the legacy service is on a clock you do not control, and the supported path requires a Unity upgrade.
Who this actually affects
If your project is already on Unity 6.2 or later, enable data collection in the editor and use Diagnostics in the Unity Dashboard. You are done.
Everyone else falls into one of three groups:
- Shipped games on an LTS version (2021.3, 2022.3, 6.0) that still get patches. Upgrading the engine for a patch is a risk most teams will not take.
- Games in production that will lock their Unity version before release, possibly below 6.2.
- Studios with more than one engine, a Godot prototype or an Unreal project beside the Unity game, who would rather have one crash dashboard than one per engine.
Your three options
Option 1: Upgrade to Unity 6.2 and use Diagnostics
The supported path. Diagnostics is integrated with the editor and dashboard, handles symbol files, and adds ANR reporting for Android. The cost is the upgrade itself: render pipeline changes, package updates, and regression testing across every platform you ship.
Option 2: Stay on your Unity version and switch crash reporting
Keep your engine version and move crash reporting to a third-party SDK that supports it. Bugnet's Unity SDK supports Unity 2020.3 and later; Sentry, Backtrace and BugSplat also have Unity integrations. This decouples crash reporting from your engine upgrade schedule.
Option 3: Combine
Use Unity Diagnostics for engine-level crash data and add a tool that covers what it does not: player-written bug reports from every platform, a public known-issues page, Steam reviews, and integrations with your planning tool.
How the options compare
| Unity Diagnostics | Bugnet | Sentry | |
|---|---|---|---|
| Unity versions | 6.2 and later | 2020.3 and later | See Sentry's Unity SDK requirements |
| Other engines | No | Unreal, Godot, GameMaker, Construct 3, Pygame, Web | Unreal, Godot, native |
| Player bug reports | Separate User Reporting package | Built-in widget, same tracker as crashes | User feedback prefab (Unity SDK 4.0+) |
| Android ANRs | Yes (Android 11+) | No | Yes |
| Bug tracker and public pages | No | Tracker, known-issues page, roadmap, changelog | No |
| Steam review sync | No | Yes | No |
| Pricing | Part of Unity's services | Free for 100 reports; $19/mo flat | Free for 5,000 errors/mo; usage-based |
Switching a Unity project to Bugnet
The integration is one C# file and takes about five minutes.
- Create a free Bugnet account and a project, then copy the project's API key.
- Install the SDK from your project root (where
Assets/lives):curl -s https://bugnet.io/sdks/unity/install.sh | bash, or the PowerShell installer on Windows. It dropsBugnetSDK.csintoAssets/Scripts/. - Add the BugnetSDK component to an empty GameObject in your first scene and enter the API key in the Inspector, or call
BugnetSDK.Instance.Init("YOUR_API_KEY", "https://api.bugnet.io"). - Turn off the legacy Cloud Diagnostics crash reporting in your project's Services settings once Bugnet reports are arriving, so the same exceptions are not tracked in two places.
- Bind the report widget to a key or pause-menu button with
BugnetSDK.Instance.ShowWidget(), which replaces a User Reporting form if you used one.
From then on, exceptions, errors and failed asserts are captured from Unity's log stream automatically, each with the last 100 log lines, the device, OS, GPU, RAM and screen resolution, the version from Player Settings and a frame-rate and memory snapshot. Identical reports stack into one bug with a count, and crash-free sessions are tracked per build. The full API is in the Unity SDK docs.
What about User Reporting?
If you use Unity User Reporting for player feedback, nothing forces you to change: Unity says it is not deprecated. The reason some teams switch anyway is that its reports live in the Unity Dashboard, separate from crash data and from wherever the team plans work. Bugnet puts player reports and auto-captured crashes in one list, can email the player when their bug is fixed, and can file the important ones into GitHub, Linear, Jira, ClickUp, Trello or Notion. See the best in-game bug reporting tools for a side-by-side.
Our recommendation
Do not let a crash reporter dictate your engine upgrade. If you are already moving to Unity 6.2 for other reasons, use Diagnostics and add a player-facing tool if you need one. If you are pinned to an earlier version, a shipped game is not the place to wait for a sunset date: move crash reporting to an SDK that supports your version now, while legacy reports are still arriving and you can compare the two.
Frequently asked questions
Is Unity Cloud Diagnostics shutting down?
Unity has deprecated Cloud Diagnostics and says it will be phased out in future versions of Unity. Its crash and exception reporting is replaced by the built-in Diagnostics service in Unity 6.2 and later. Unity has not published a final shutdown date and says live games will not be interrupted while projects migrate.
Is Unity User Reporting deprecated?
No. Unity has said User Reporting is not deprecated. It continues as a separate package that is compatible with Diagnostics in Unity 6.2 and later.
Do I have to upgrade to Unity 6.2 to keep crash reporting?
To use Unity's own replacement, yes: Diagnostics requires Unity 6.2 or later. If you cannot upgrade, you can switch to a third-party crash reporter that supports your version, such as Bugnet, which supports Unity 2020.3 and later.
What happens to my existing Cloud Diagnostics data?
Cloud Diagnostics retains data for 7 or 90 days depending on your Unity plan. Download any reports you want to keep as JSON during that window.
Can I use Bugnet and Unity Diagnostics together?
Yes. Some teams keep Unity Diagnostics for engine-level crash data and ANRs and use Bugnet for player bug reports, Steam reviews, public known-issues pages and integrations with their planning tools.
Crash reporting is plumbing. Pick the kind that does not need you to rebuild the house to keep the water running.