What do you dislike about Sentry?
Sentry has grown into a much bigger product than it was a few years ago. Issues, Explore, Traces, Logs, Metrics, Profiles, Releases, Monitors, and Seer add a lot of depth, but that breadth can also feel disorienting for a developer who opens the platform simply trying to understand a single exception. I’d prefer the initial experience to adapt more clearly to the task at hand, rather than immediately exposing the entire observability surface. Review collected by and hosted on G2.com.
Recommendations to others considering Sentry:
We really saw the value of the full stack when an ASP.NET Core release introduced a regression that only affected customers with a specific configuration. The first sign was a slight uptick in 500 errors—noticeable, but not enough to trigger our usual infrastructure alerts. In Sentry, the exceptions were grouped in a way that made the pattern clear: the affected users shared the same feature flag and the same release. From the issue, we opened the trace and could see the request spending far longer than expected in a SQL call before it ultimately failed. Suspect Commit then narrowed our search even further by pointing us to the refactor where configuration loading had changed, which gave us a much smaller area to investigate. After we shipped the fix, we used Application Metrics to confirm the error rate returned to baseline, rather than assuming the incident was resolved just because the deployment completed successfully. We also realized our original alert was too sensitive and kept notifying on transient failures, so we replaced it with a Monitor that accounted for both rate and volume. Sentry didn’t eliminate the debugging work, but it did put the error, trace, release, and user impact on a single investigation path. That reduced the time we normally spend correlating logs across services and gave us a much better way to prove the fix actually worked in production. Review collected by and hosted on G2.com.
What problems is Sentry solving and how is that benefiting you?
We really saw the value of the full stack when an ASP.NET Core release introduced a regression that only affected customers with a specific configuration. The first sign was a slight uptick in 500 errors—noticeable, but not enough to trigger our usual infrastructure alerts. In Sentry, the exceptions were grouped in a way that made the pattern clear: the affected users shared the same feature flag and the same release. From the issue, we opened the trace and could see the request spending far longer than expected in a SQL call before it ultimately failed. Suspect Commit then narrowed our search even further by pointing us to the refactor where configuration loading had changed, which gave us a much smaller area to investigate. After we shipped the fix, we used Application Metrics to confirm the error rate returned to baseline, rather than assuming the incident was resolved just because the deployment completed successfully. We also realized our original alert was too sensitive and kept notifying on transient failures, so we replaced it with a Monitor that accounted for both rate and volume. Sentry didn’t eliminate the debugging work, but it did put the error, trace, release, and user impact on a single investigation path. That reduced the time we normally spend correlating logs across services and gave us a much better way to prove the fix actually worked in production. Review collected by and hosted on G2.com.
