We’re announcing the deprecation of the legacy Cloud Diagnostics package, and will be phasing it out over the coming months. This move allows us to provide you with a more powerful and efficient diagnostics experience that’s embedded in your project details in the Dashboard, and is available now in Unity 6.2. We strongly encourage new users and projects to use the new Diagnostics experience to benefit from the latest features and longer-term support.
Why the change?
The new diagnostics solution offers significant improvements, including ANR (Application Not Responding) reporting, support for more performance and stability data (including runtime and services observability), and session breadcrumbs. This new experience is built on modern infrastructure to enable us to deliver more of the features you’ve been asking for, more quickly.
What does this mean for you?
Over the coming months, we will be phasing out legacy Cloud Diagnostics, including no longer allowing new projects and users to utilize it. For existing users, we are committed to making this transition as smooth as possible with no interruption to current live games using legacy Cloud Diagnostics’ crash reporting. In order to achieve this, our plan is to migrate all legacy Cloud Diagnostics projects to the new stack, with client-side data being proxied through to the new Diagnostics service. Once a majority of projects - with our priority moving all active live games over - we’ll fully sunset and remove the legacy Cloud Diagnostics package and service.
What about User Reporting?
User Reporting will continue to be a companion package for our new Diagnostics solution, available for continued usage by existing users and net new users or projects.
Next Steps:
We will be posting a more detailed update outlining the timeline and migration process. Stay tuned for more information on how to leverage the new Diagnostics solution and ensure a seamless transition! We’re excited about the improved capabilities this change will bring to your live game development workflow.
Hi, I just tried the new diagnostic dashboard and it seems that custom metadata set with CrashReportHandler.SetUserMetadata are not visible and not available in the filter list. It would be good to add back the isEditor filter (or maybe the crash are not sent from the editor anymore ?)
On Cloud Diagnostic, we have access to sessions logs set with Debug.Log but it seems that with the new experience, there is just session pause/resume. Logs was very helpful in certain cases and it would be great to keep access to them.
For the moment I highly prefer the old Cloud Diagnostic compared to the new experience.
Thank you for your feedback! It’s really helpful to understand what capabilities current users get the most value out of in our planning to determine final feature set before determining sunset date. We have the additional filters for custom metadata and isEditor in the backlog, and are exploring unlocking custom logging within the new Diagnostics. As part of that, I would love to understand more your specific needs here … when would having the Debug.Log available be helpful? Are you just looking for a 1:1 feature mapping from the old diagnostics (having the configurable last N of Debug.Logs attached to the stack trace if an error occurs)?
Thanks for your reply!
It’s great to hear that you’re planning to add custom metadata; it’s incredibly useful for tracking down bugs related to a specific game state or a particular user.
Regarding my Debug.Log usage:
I use Debug.Log extensively to check for unexpected behaviors in my games.
The current cloud diagnostics don’t seem to retain the full exception message, keeping only one from a group. Because of this, I often add a Debug.Log with extra information right before sending an exception (Debug.LogException).
For other exceptions, having context about what happened beforehand is very helpful. I always add logs for important user and game actions so I can easily debug issues. Knowing a user’s actions leading up to a bug is crucial for reproducing and fixing it.
In earlier versions of Unity, we didn’t have line numbers for errors, so adding logs within large problematic functions was also very helpful.
Currently, the limit of 50 logs has been sufficient for my needs.
I’m really looking forward to seeing what other new features you’ll be implementing.
We’re also using logging pretty extensively in my team as a means to provide context on what the user might have been doing before the crash or exception happened. It’s a pretty core feature for debugging on our end as far as I’m concerned, both in terms of our own logs and potential engine logs that also might pop up when something goes wrong.
Beyond that, I’m not sure I quite understand how we are supposed to move old projects over to using the new diagnostics service. Based on what I’m reading here and in the docs, diagnostics is now a part of the core engine as of 6.2 so we’re supposed to remove the old “Cloud Diagnostics” package and then either enable/disable diagnostics data in the project settings (for defaults) or in a build profile.
I’ve recently updated to 6.2 to look into how the new diagnostics functionality works (because I keep seeing these popups in the dashboard that the old one is deprecated and we need to move over to the new one!), but cant really seem to get it to work. When “Diagnostics Data” is set to “Enabled” in my build profile, no data seems to be received over in the new dashboard when testing with a Debug.LogException(). Instead, it seems like my exception pops up in the old cloud diagnostics dashboard. I’ve removed the old cloud diagnostics package at least so I’d assume whatever is sending the exception now is the new backend for it.
There’s also a mention in the docs and dashboard that you can configure the settings for what type of “Developer Data” is collected, but whenever I go to where the docs tell me to (i.e. Project → Settings in the dashboard), there is no button anywhere to configure it. Is this something related to the migration mentioned in the original post where we have to wait for migration to finish before we can access things? I think it might be worth clarifying what developers are expected to do to properly move over to the “new diagnostics” for existing projects at least .
New Diagnostics sends session data regardless of user’s consent settings.
This was reported by our team here:
This was confirmed by the Unity team, so it looks like it is not safe to use New Diagnostics until it’s fixed or otherwise you would likely be violating your privacy obligations.
Does anyone know if there has been any progress on Unity’s end in addressing this?
Does anyone know if there’s a workaround or some undocumented way to opt in/out of New Diagnostics at runtime?
This behavior is because Diagnostic Data isn’t controlled by the Consent Module. The reason for this is that Diagnostic Data is a subset of Essential Data which is allowed to be collected without direct user consent (it is software / hardware performance information not containing any PII).
Additionally, Diagnostic Data is not managed at the user level, and is instead toggled at the project level via the Project Settings. If you don’t feel comfortable collecting this data from your users, you can turn it off, but unfortunately, there currently isn’t a way to control this on a player by player basis (I can certainly surface this as a feature request though).
TL;DR: this is the current intended behavior and isn’t a bug.
Treating this as essential data sounds questionable. The session data is not required for our game to function and depending on interpretation and jurisdiction might be considered analytics data.
Even if we stretch the definition of what essential data is, we want to respect our players’ choices: Our game asks them for consent before sending any analytics data and if they refuse, we do not wish to send any session data. Ideally, the game should not make any outgoing network connections.
Understood. Unity’s stance is based on our legal team’s compliance with the various regions’ laws. That being said, it is up to each individual to work with their own legal counsel to determine how they’d like to interpret it. In this regard, I can say that the umbrella of “essential data” extends to cover any data that helps for the efficient operation of a piece of software, which is why diagnostic data is covered.
Let me reuse an analogy that I posted in another thread: Let’s say you take your car to the mechanic for a check up (maybe it’s making a weird noise or something). Most modern cars have an onboard computer system and the mechanics will hook into that and pull diagnostic data about your vehicle. Consent for them to look at this data is implied by you being there. Furthermore, it is likely that your car could operate without this data, and more so, they could likely fix your car without this data, though not as easily. But still, that diagnostic data, collected by the car and viewed by the mechanic, is seen as essential to the smooth operation of your vehicle.
To take the metaphor one step further, you could ask the mechanic not to view that data (opt out) just like you can turn off this diagnostic data. Most people don’t though, because just like our usage of “diagnostic data”, there isn’t any PII. It is just hardware and operation statistics that let us (and you) better understand how the engine (see what I did there?) is running in the real world.
Anyway, none of this is legal advice from me or Unity. It is just how we are approaching it
In the original post, You mention session breadcrumbs as a new feature.
Is it possible to add my own custom breadcurmbs? (like level transition). Because so far, I pretty much only get ‘session started’ and ‘session ended’ breadcrumbs which is not very helpful at all. I’m not sure what the point of them is.
I understand that Unity’s approach regarding essential data might make sense on mobile where everyone expects the apps to make outgoing connections. The apps themselves usually can’t work without the internet, and the OSes don’t have firewall prompts.
But on desktop this would likely enrage our players who explicitly said “No” to our analytics consent, and who did not read or accept our privacy policy. We wish to respect their choice, as I am sure other developers of desktop games would, especially those who make single-player games.
What Unity should do is let developers make this decision themselves. We have a couple hundred thousand of players who opted out of analytics and data sharing, larger developers likely have millions. It is the developers who should weigh this against any legal or reputational risks.
I will ensure that the team sees this feedback. The features are still new so all feedback and insight is appreciated while we continue to make them more mature
Hi,
Will the New Diagnostics support an Debug symbols API to upload debug symbols?
This is something that we have been missing for our CI pipeline for a long time.
It’s been nearly 6 months since the deprecation of Legacy Cloud Diagnostics for the new one, but the new dashboard still feels like a step backward for our debugging workflow. While we appreciate the modernization effort, several critical features are still missing:
Advanced Filtering: We really need the ability to filter by Custom Metadata and Issue Type (Exception, Crash, ANR). Currently, finding specific issues is far more time-consuming than it used to be.
Detailed Issue Logs: The absence of the Debug.Log history and Custom Metadata directly on the issue page makes it nearly impossible to understand the context of a crash.
Breadcrumbs: The current breadcrumbs are unfortunately quite limited. Seeing only session start/pause/resume doesn’t provide the technical context needed to reproduce complex bugs. We need more granular events, maybe you could add an API to add events on the breadcrumbs (or just keep the logs).
Is there a roadmap for implementing these essential features? Furthermore, is there active development happening on this tool, or is the current state considered final? Any transparency on the upcoming updates would be greatly appreciated.
.