Attachments
Learn more about how Sentry can store additional files in the same request as event attachments.
Sentry can enrich your events for further investigation by storing additional files, such as config or log files, as attachments.
You can use a higher-level SDK for platforms with built-in support for native crashes, or generate and upload attachments using the API:
To receive symbolicated stack traces, you have to upload debug information to Sentry. Unless the option to store crash reports is enabled, Sentry will use the crash reports only to create the event, then will drop the files. For more information, see Debug Information Files.
To send attachments directly to Sentry, add more files to the multipart form body. Note that the entire request must not exceed 20MB in size, even with compressed content encoding. Sentry will use the provided file names and mime types and list those files in the Event Attachments section at the bottom of the Issue Details page:
curl -X POST \
'https://o0.ingest.sentry.io/api/0/minidump/?sentry_key=examplePublicKey' \
-F upload_file_minidump=@mini.dmp \
-F some_file=@some_file.txt \
-F db_log=@db.log
Sentry allows at most 20MB for a compressed request, and at most 100MB of uncompressed attachments per event, including the crash report file (if applicable). Uploads exceeding this size are rejected with HTTP error 413 Payload Too Large and the data is dropped immediately. To add larger or more files, consider secondary storage options.
Usually, native crash reports range from a few kilobytes to a few megabytes. This leaves sufficient space to add custom attachments. In case your application generates particularly large crash reports, consider to limit or avoid adding additional attachments in the SDK.
Attachments persist for 30 days; if your total storage included in your quota is exceeded, attachments will not be stored. You can delete attachments or their containing events at any time. Deleting an attachment does not affect your quota - Sentry counts an attachment toward your quota as soon as it is stored.
Learn more about how attachments impact your quota.
Crash reports may contain sensitive information about the target system, such as environment variables, local pathnames, or in-memory representations of input fields, including passwords. By default, Sentry only uses crash report files to create events and immediately drops them. All sensitive information is stripped from the resulting events.
All other types of attachments, such as log files or screenshots, are stored for 30 days when sent to Sentry. Note that Sentry does not apply data scrubbing to attachments.
You can enable Store Native Crash Reports in your organization's Security and Privacy Settings. By default, this setting is disabled. Determine the maximum number of crash reports that will be stored per issue; disabled, unlimited, or maximum per issue:
If you set a limit per issue, as in the example above, a limit of 10, Sentry will store the first 10 attachments associated with this issue, but drop any that follow. To make room for additional attachments, delete them. Sentry will then accept attachments until the limit is reached again.
To limit access to attachments, navigate to your organization's General Settings, then select the Attachments Access dropdown to set appropriate access — any member of your organization, the organization billing owner, member, admin, manager, or owner.
By default, access is granted to all members when storage is enabled. If a member does not have access to the project, the ability to download an attachment is not available; the button will be greyed out in Sentry. The member may only view that an attachment is stored.
Attachments display on the bottom of the Issue Details page for the event that is shown.
Alternately, attachments also appear in the Attachments tab on the Issue Details page, where you can view the Type of attachment, as well as associated events. Click the Event ID to open the Issue Details of that specific event.
If you chose to limit the number of crash reports per issue, you can show Only Crash Reports. This removes all other attachments from the list, which can be useful if the issue has accumulated a large number of events.
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").