Reprocessing

Sentry uses debug information files only after they have been uploaded. Reprocessing allows you to apply debug information files to error events that have already occurred.

After becoming an Early Adopter, you will find a new button when viewing an issue:

The dialog requires two answers:

• How many events to reprocess: When left empty, all events are reprocessed and potentially move to other (new or existing) issues if the stack trace changed significantly. If you provide a number, for example, 20, then the 20 most recent events are reprocessed, and any remaining events are left as-is.

• What to do with remaining events: If you choose to reprocess, for example, only 20 events out of 100, you can choose what happens to the remaining 80 events. The default is to keep them where they are (the issue you're viewing). Alternately, you may choose to delete them.

After pressing "Reprocess Events", the issue is locked and hidden from your issue stream while reprocessing is ongoing. As data is migrated between issues, sentry.io doesn't allow any actions, such as resolving or assigning the issue, to ensure data consistency and to avoid data loss.

Note that you can still get to the issue manually by searching for is:reprocessing (removing all other search terms) if you need to.

Caveats

The dialog to start reprocessing notes a few caveats that you should be aware of and understand before you begin reprocessing.

• Native only. Reprocessing is only available for native events, and events containing native frames. On issues that do not contain native events, the button is hidden.

• Data glitches. During reprocessing you may observe temporary data inconsistencies across the entire product. You may observe that an event belongs to two issues at once, and appears in Discover queries twice.

  Those inconsistencies disappear when reprocessing is complete. However, depending on your platform and the number of events involved, reprocessing may take a while.

• Attachment storage needs to be enabled. If your events come from minidumps or unreal crash reports, you must have attachment storage enabled. If the original minidump no longer exists in Sentry, sending an event through reprocessing will cause it to have no stack trace at all.

• Quota applies. Every event you choose to reprocess counts against your plan's

  quotaThe monthly number of events that you pay Sentry to track.
  a second time. Rate limits and spike protection do not apply.

• Debug files don't apply immediately. When you upload debug information files, regardless of whether you upload to your own symbol server or to Sentry, the debug information files are applied only one hour after internal caches have expired. Please wait at least an hour after uploading DIFs before reprocessing.

• Alerts do not apply, with caveats. Issue alerts do not trigger for reprocessed events, and the new events are not subject to data forwarding.

  Metric alerts generally do not trigger either. However, they are subject to the data inconsistencies listed above. If you've created a metric alert with a 24-hour measurement window, and an event you reprocess happened in the last 24 hours, it will temporarily be counted twice while events are reprocessing. This may trigger a metric alert.

Legacy Reprocessing

Sentry can suspend incoming crash reports until all required debug information files have been uploaded. This feature is also called Reprocessing. It can be configured in [Project] > Settings > Processing Issues. By default, this feature is disabled.

If this feature is enabled, crash reports with missing debug files are not displayed in the issues stream. Instead, you will receive a warning that events cannot be processed until all debug files have been uploaded.

We do not recommend enabling this project setting as it does not work properly with minidumps or Unreal crash reports. Reprocessing existing issues as shown above replaces this functionality.