Uploading Files
The most straightforward way to provide Sentry with debug information file is to upload them using sentry-cli
. Depending on your workflow, you may want to upload as part of your build pipeline or when deploying and publishing your application:
wasm-split /path/to/myfile.wasm -d /path/to/myfile.debug.wasm --strip
sentry-cli debug-files upload -o <org> -p <project> /path/to/files
> Found 1 debug information files
> Prepared debug information files for upload
> Uploaded 1 missing debug information files
> File processing complete:
PENDING 1ddb3423-950a-3646-b17b-d4360e6acfc9 (mylib; wasm debug companion)
For all available options and more information refer to Uploading Debug Information.
Debug files should be uploaded before deploying or releasing your application so that crash reports can be processed. For manual testing, use the sentry-cli debug-files upload --wait
before sending the first native crash or error event.
If you upload a file that was previously reported as missing by Sentry in a crash report, it may take up to one hour until Sentry starts using this file for new crash reports. Existing events and issues are not processed again.
In Sentry, your uploaded files are associated with projects. You can view and manage uploads at Project Settings > Debug Files. This screen displays the most important properties of debug files:
- The debug identifier. There may be multiple entries sharing the same identifier, if debug information is split across multiple files.
- The name of the debug file. Sentry uses the name on the file system when uploading the file using
sentry-cli
. - The architecture, and type of the file. This can be used to distinguish files into executables and debug companions if their debug identifiers and names match.
- The debug information available in these files. This can include
unwind
,debug
,symtab
andsources
. - Metadata like the size and time of upload.
If multiple projects require the same file, it needs to be re-uploaded. Sentry does not access debug files stored in other projects to symbolicate crash reports.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").