#No crash data sent from Unreal Enginge shipping build
1 messages · Page 1 of 1 (latest)
Based on the docs and issues in the knowledge sources, there are a few Unreal‑specific pitfalls to check.
1. Crash capture mechanism (Sentry SDK vs UE Crash Reporter)
On Windows with UE 5.2+ you must choose either:
- Sentry’s own crash capturing (
sentry-nativevia the plugin), or - UE Crash Reporter Client (CRC) sending to Sentry.
They are mutually exclusive and can’t be used at the same time. [Unreal overview; Crash Reporter docs]
If you’re on UE 5.2+ and using the Sentry plugin:
- In Project Settings → Plugins → Sentry, ensure “Enable automatic crash capturing (Windows, UE 5.2+)” (or similarly named option) is enabled if you want Sentry to capture crashes directly. [Crash Reporter docs]
- If you instead want to use the UE Crash Reporter, you must:
- Enable Include Crash Reporter in Project → Packaging → Show Advanced → Include Crash Reporter. [Include Crash Reporter]
- Configure the CrashReportClient endpoint (
DataRouterUrl) with your Sentry Unreal Engine Endpoint inEngine/Programs/CrashReportClient/Config/DefaultEngine.ini. [Configure endpoint]
If both are partially configured (e.g. CRC enabled but no endpoint, or Sentry crash capture disabled), editor crashes may still show up (because the editor uses a different path), while shipping builds don’t send anything.
2. Crash Reporter not included in shipping builds
If you rely on the UE Crash Reporter path (not Sentry’s native crash capture), make sure:
- Include Crash Reporter is enabled in your project’s packaging settings; otherwise shipping builds won’t show the crash dialog or send reports. [Include Crash Reporter]
There’s also a separate Include Debug Files option that must be enabled for Sentry to symbolicate native crashes; without it, crash reports are effectively useless even if they arrive. [Onboarding note]
3. Engine version differences
- UE ≤ 5.1 (Windows): Sentry cannot fully replace CRC for crash capture; you must configure the UE Crash Reporter to send to Sentry. [Unreal overview]
- UE 5.2+ (Windows): Sentry plugin can capture crashes directly; CRC configuration is no longer required and should generally be disabled if you use Sentry’s crash capture. [Unreal overview; Issue 977 comment]
If you followed an older guide that still mentions always configuring CrashReportClient, that can be misleading for UE 5.2+ when using the SDK. [Onboarding wizard issue; Issue 977 comment]
4. Platform coverage
CRC only exists on desktop (Windows, macOS, Linux). For mobile and consoles, you must use the Sentry SDK; CRC will never send anything there. [Crash Reporter docs]
5. Things to verify in your project
Given the above, for a shipping build that sends no crashes:
- Confirm engine version and platform (e.g. Windows UE 5.2+ vs older).
- Decide on one crash path:
- Sentry plugin crash capture enabled, CRC not configured, or
- CRC included and configured with Sentry Unreal Endpoint, Sentry plugin used only for enrichment.
- If using CRC:
Include Crash Reporteris checked in Project → Packaging. [Include Crash Reporter]DataRouterUrlinCrashReportClientsection ofDefaultEngine.inipoints to your Sentry Unreal Engine Endpoint. [Configure endpoint]
- If using Sentry’s crash capture (UE 5.2+ on Windows):
- The Sentry plugin is installed in the project and enabled. [Unreal overview]
- Automatic crash capturing is enabled in the plugin settings. [Crash Reporter docs]
- Ensure debug files are included in packaging so Sentry can symbolicate crashes. [Onboarding note]
If you share your UE version, target platform, and whether you configured CrashReportClient or rely solely on the plugin, I can help narrow down which of these is most likely affecting your shipping build.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
@stiff totem Our robots are still learning and improving, please let us know if this response was correct by reacting below.
Let me check the knowledge base for you again. One moment! :books:
Yes — if you’re using “Enable automatic crash capturing (Windows, UE 5.2+)” (that is, Sentry’s own crash capturing via sentry-native), you generally do not need to configure Engine/Programs/CrashReportClient/Config/DefaultEngine.ini.
Key points from the docs and issues:
- Starting with UE 5.2, Sentry can capture crashes directly on Windows without going through the UE Crash Reporter Client (CRC). The CRC configuration step “isn't required” in that case. [Unreal overview]
- The Crash Reporter endpoint in
DefaultEngine.iniis specifically for integrating UE Crash Reporter with Sentry. [Configure endpoint] - For UE 5.2+ it’s recommended to pick one mechanism: either CRC or Sentry’s native crash capture. They are mutually exclusive on Windows. [Crash Reporter docs; Issue 404]
- A maintainer explicitly notes that for UE 5.5 there’s “no need to use CRC at all since Sentry SDK can now fully handle crash capturing on its own,” and suggests resetting CRC configuration and leaving the endpoint empty. [Issue 977]
So, if you enable automatic crash capturing in the Sentry plugin on UE 5.2+ and intend to rely on Sentry’s native integration, you should not need to set the Crash Reporter endpoint in DefaultEngine.ini, and you can leave it empty or reset it.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
@stiff totem Our robots are still learning and improving, please let us know if this response was correct by reacting below.
Let me check the knowledge base for you again. One moment! :books:
There is some relevant information, but the knowledge sources don’t fully cover all troubleshooting steps for sentry-native in Unreal, so I’ll focus on what is documented and where to look.
1. Confirm that native crash capturing is actually enabled
On UE 5.2+ (Windows), the Sentry plugin can use sentry-native instead of the UE Crash Reporter. This is controlled by the “Enable automatic crash capturing (Windows, UE 5.2+)” toggle in:
Project Settings → Plugins → Sentry
A maintainer explains that when this is checked, Sentry uses sentry-native and disables the UE Crash Reporter; when it’s unchecked, UE’s Crash Reporter is used instead. They are mutually exclusive. [Issue 404 comment; Crash Reporter docs]
So verify:
- Automatic crash capturing is enabled in the plugin.
- You’re not relying on Crash Reporter configuration in
DefaultEngine.inifor this mode.
2. Check that Sentry is enabled for the right build targets
The plugin has a “Enable for Build Target Types” setting that controls for which targets sentry-native is initialized. If your current target (e.g. Editor, Game, Server) is disabled there, Sentry won’t initialize and no crashes will be captured. A maintainer describes using this to have Sentry-native on servers while leaving Crash Reporter active on clients. [Unreal crash reporter discussion]
Action: In Project Settings → Plugins → Sentry → Misc, make sure the target type you’re running (Editor / Game / Server) is checked.
3. Look for local crash dump files from sentry-native
When sentry-native captures a crash, it writes a dump file locally. A collaborator notes that these are stored under:
<BuildDir>/<ProjectName>/.sentry-native/reports[Issue 329 comment]
If you trigger a crash and no file appears there, it strongly suggests that:
sentry-nativeis not actually enabled/initialized for that target, or- Another crash handler is taking over first.
If dumps are present locally but nothing shows up in Sentry, the problem is likely network/configuration (DSN, auth, etc.), but the knowledge sources don’t give more detail on that path.
4. Don’t mix Crash Reporter and native integration
For UE 5.2+ on Windows:
- Using
sentry-native(automatic crash capturing) means you should not rely on UE Crash Reporter or its endpoint configuration. [Unreal overview; Crash Reporter docs; Issue 404 comment] - If Crash Reporter is still enabled or misconfigured, it can interfere (for example, you might expect the Crash Reporter UI but it won’t appear when native capturing is active). [Issue 404 comment]
Action: For a pure sentry-native setup, you can:
- Leave the Crash Reporter endpoint empty / reset.
- Optionally disable “Include Crash Reporter” in packaging if you don’t want CRC at all. [Issue 271 comment]
5. Logs / diagnostics
The knowledge sources don’t explicitly document a dedicated Sentry log file for the Unreal plugin. The only concrete diagnostic artifact mentioned for native integration is the local dump directory above. [Issue 329 comment]
So, from the available docs/issues, the most actionable checks are:
- Automatic crash capturing is enabled in the Sentry plugin (Windows, UE 5.2+). [Crash Reporter docs]
- Your current build target type is enabled under “Enable for Build Target Types”. [Unreal crash reporter discussion]
- After a test crash, verify whether a dump appears in
<BuildDir>/<ProjectName>/.sentry-native/reports. [Issue 329 comment] - Ensure you’re not unintentionally mixing CRC and native integration (CRC endpoint config is not required for native mode). [Unreal overview; Issue 404 comment]
If you can share your UE version, platform, and whether you see anything in .sentry-native/reports, that would help narrow down whether the issue is initialization vs. upload.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
@stiff totem Our robots are still learning and improving, please let us know if this response was correct by reacting below.
Let me check the knowledge base for you again. One moment! :books:
That log line means the Sentry SDK sent a request to Sentry’s servers and Sentry responded with HTTP status 403 Forbidden. In other words, the request reached Sentry but was rejected.
From the available knowledge, common 403 causes include:
- IP/network being blocked – for example, some Hetzner IP ranges are blocked by Google Cloud Platform, which Sentry uses. In that case you must request a different IP from your provider. [403 Hetzner IPs]
- Permission / auth problems – Sentry can respond with 403 when the token or project/organization permissions don’t allow the requested action (for example, “You do not have permission to perform this action.”). [Self-hosted 403]
- Project/DSN issues – for event submission, a 403 with a message like
event submission rejected with_reason: ProjectIdindicates a DSN or project backend setup problem. [ProjectId 403]
The log you posted is just the Unreal plugin surfacing that 403; to know which of the above applies, you’d need to inspect the full HTTP response body (if any) or Sentry server logs. The knowledge sources don’t include Unreal‑specific 403 troubleshooting beyond these general causes, so I can’t be more precise than that.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
@stiff totem Our robots are still learning and improving, please let us know if this response was correct by reacting below.
Let me check the knowledge base for you again. One moment! :books:
This log shows that your Unreal client successfully reached Sentry’s SaaS endpoint, but Sentry rejected the envelope with HTTP 403.
From the headers:
Via: 1.1 googleandServer: nginxindicate the request hit Sentry’s infrastructure on Google Cloud.- A 403 in this context typically means either:
- Network/IP is blocked by Google Cloud, or
- Sentry rejected the request for permission / project reasons.
The only concrete 403 cause explicitly documented for event sending is blocked Hetzner IP ranges: Google Cloud is known to deny some Hetzner IPs, and Sentry (hosted on GCP) will return 403 for all requests from those IPs. The recommended fix is to request a different IP from Hetzner. [403 Hetzner IPs]
Separately, Sentry can also return 403 for permission/auth issues (for example, when an API token doesn’t have rights for the requested action), but the knowledge sources don’t show the exact JSON body for your case, so I can’t say which applies here. [Self-hosted 403]
Given the available information:
- If you’re running from a Hetzner-hosted machine, the most likely cause is the GCP/Hetzner IP block; you’d need to get a new IP from Hetzner. [403 Hetzner IPs]
- Otherwise, the knowledge sources don’t provide enough detail to pinpoint the exact reason; you’d need to inspect the response body (the 61‑byte JSON) or Sentry’s server logs to see the specific error message.