ElectronAttachments
Sentry can enrich your events for further investigation by storing additional files, such as config or log files, as attachments.
You'll first need to import the SDK, as usual:
import * as Sentry from "@sentry/electron";
Attachments live on the Scope and will be sent with all events.
// Add an attachment
Sentry.getCurrentScope().addAttachment({
filename: "attachment.txt",
data: "Some content",
});
// Clear attachments
Sentry.getCurrentScope().clearAttachments();
An attachment has the following fields:
filename
The filename is required and will be displayed in sentry.io.
data
The content of the attachment is required and is either a string or Uint8Array.
contentType
The type of content stored in this attachment. Any MIME type may be used; the default is application/octet-stream.
It's possible to add, remove, or modify attachments before an event is sent by way of the beforeSendhook or a global event processor.
Sentry.init({
dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
beforeSend: (event, hint) => {
hint.attachments = [{ filename: "screenshot.png", data: captureScreen() }];
return event;
},
});
Sentry.addGlobalEventProcessor((event, hint) => {
hint.attachments = [{ filename: "log.txt", data: readLogFile() }];
return event;
});
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.
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").
