Problem Statement
Console crashes reach Sentry through a platform-operated crash pipeline and vendor
middleware before Sentry ever sees them. When the count in the platform's own
dashboard does not match the count in Sentry, there is no way for the application
team to find out where the difference came from: whether the event was never
forwarded, was rejected at ingestion, was filtered, or was dropped for quota.
The consequence is not just a missing number. Once a team observes one mismatch they
stop trusting the crash pipeline generally, and every subsequent gap in the data is
attributed to tooling rather than investigated. That is an expensive failure mode to
recover from, and it is caused by a visibility gap rather than by any actual data
loss.
Application teams have no administrative view into the middleware layer and no way
to reason about it. Outcome data exists in aggregate but is not exposed for this
ingestion path in a way that answers "where did this specific crash go".
Solution Brainstorm
- Expose per-event outcomes and reasons for console-pipeline ingestion, queryable by
the application team.
- Provide a processing view for this path showing what arrived at the middleware,
what was forwarded, and what was rejected with a reason.
- Where Sentry genuinely cannot see upstream of its own middleware, state that
boundary explicitly in the UI, so teams know which side of the line a gap falls on
rather than assuming the worst.
Product Area
Ingestion
Requested by Saad Khan.
--
View Junior Session [Sentry]
Problem Statement
Console crashes reach Sentry through a platform-operated crash pipeline and vendor
middleware before Sentry ever sees them. When the count in the platform's own
dashboard does not match the count in Sentry, there is no way for the application
team to find out where the difference came from: whether the event was never
forwarded, was rejected at ingestion, was filtered, or was dropped for quota.
The consequence is not just a missing number. Once a team observes one mismatch they
stop trusting the crash pipeline generally, and every subsequent gap in the data is
attributed to tooling rather than investigated. That is an expensive failure mode to
recover from, and it is caused by a visibility gap rather than by any actual data
loss.
Application teams have no administrative view into the middleware layer and no way
to reason about it. Outcome data exists in aggregate but is not exposed for this
ingestion path in a way that answers "where did this specific crash go".
Solution Brainstorm
the application team.
what was forwarded, and what was rejected with a reason.
boundary explicitly in the UI, so teams know which side of the line a gap falls on
rather than assuming the worst.
Product Area
Ingestion
Requested by Saad Khan.
--
View Junior Session [Sentry]