Surface outcome and reason in the app, and support a per-event answer to "why is this event not in Sentry"

Problem Statement

When an expected event does not appear in Sentry, there is no self-service way to
find out why. The event may have been rate-limited, matched by an inbound filter,
dropped by dynamic sampling, rejected as invalid, discarded by a client-side
callback, or dropped for quota.

The data partly exists already: organization stats can be grouped by project,
outcome, and reason through the API. Two gaps remain:

1. The app does not show outcome and reason together, so the information is only
   reachable by someone willing to script against the API.
2. Even with the API, the granularity is aggregate. It cannot answer the question
   that is actually asked, which is always about one specific event that one
   specific engineer expected to see.

The same gap applies to attachments. An event arrives but the minidump or log file
attached to it does not, and there is no indication of what happened to it.

The consequence for teams that filter aggressively is a ratchet. Because they cannot
see what they are dropping, every filtering decision is made conservatively and
never revisited, and the absence of an event is indistinguishable from the absence
of instrumentation. Support escalation ends up being the only reliable path to an
answer, which does not scale for either side.

Solution Brainstorm

• Surface outcome and reason together in the app, not only through the stats API.
• A per-project processing log, retained for a short window, listing recently
  rejected and dropped events with the reason and the specific rule responsible.
• Support lookup by event ID, so the question can be asked about the one event that
  prompted it.
• Apply the same to attachments: show when an attachment was received, rejected, or
  dropped, and why.
• Where an inbound filter or sampling rule is the cause, name the specific rule, so
  the team can act on it rather than just knowing that something matched.

Related: getsentry/support#52

Product Area

Ingestion

Requested by Saad Khan.

--

View Junior Session [Sentry]

Start by reviewing the existing organization stats API grouping by project, outcome, and reason, then inspect the ingestion area of the app and related getsentry/support#52. Clarify which brainstorm items are in scope—aggregate UI, per-event lookup, attachments, or rule attribution—and define acceptance criteria for showing outcome and reason and explaining an event’s absence.