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.
The combination of Tracing, Logs, and Application Metrics is what moved Sentry beyond basic error monitoring for us. Since the .NET SDK began supporting metrics and Application Metrics became generally available, we’ve been able to track counters, gauges, and distributions, break them down by attributes like region or plan, and then pivot from an anomaly straight into the related trace, log, or error—without having to manually line up timestamps across multiple systems. We ran into this recently when auth failures started creeping up. The metric made the trend obvious, but the real value was being able to jump into the affected requests and see exactly where the failure was occurring. Monitors & Alerts have also become easier to manage because the signal and the notification path can be handled separately. A threshold can create an issue with the right context, while Slack, email, or PagerDuty routing is maintained independently. That separation helped us eliminate several duplicated alert rules that had slowly accumulated across projects. Cross-Event Querying is another feature I’m using more during technical reviews now, not only after incidents. Being able to search across spans, logs, and metrics makes it much easier to investigate a suspicious pattern early, before it turns into something urgent. The API improvements around traces, profiles, and attachments have also been helpful when we want to pull parts of that investigation into our own internal tooling, rather than forcing every workflow through the dashboard. Review collected by and hosted on G2.com.
