.NET fails in two different ways, and you want both covered. There's the hard crash, the process dies, often down in native or interop code, and there's the unhandled exception, the far more common case where something throws, a feature breaks, and the app limps on or dies depending on where it happened. A tool that only catches one of those is missing most of what actually goes wrong in a .NET app.
BugSplat catches both. Thrown exceptions get reported with their full stack trace, message, and any context you attach. Hard crashes get captured and symbolicated. Everything lands in one dashboard, grouped by root cause and versioned, so a recurring NullReferenceException shows up as one problem with a count, not a hundred separate tickets.
Exception reporting is the part you'll use every day
For most .NET apps, the day-to-day value is in the exception reporting, and it's genuinely quick to wire up. You install the NuGet package, create a BugSplat instance at your app's entry point with your database, application, and version, and you can post exceptions directly:
var bugsplat = new BugSplat(database, application, version);
// ...
await bugsplat.Post(ex);
You can set defaults once, description, email, user, key, file attachments, custom attributes, so every report carries the context you care about without you rebuilding it each time. And you can attach files to individual reports when a particular exception needs a log or a config dump to make sense.
The thing that makes this useful rather than just noisy: BugSplat groups exceptions by their signature, so you see which exceptions are happening and how often, not an undifferentiated stream. That's what lets you triage by impact instead of by recency.
Hooking the exceptions you'd otherwise miss
The exceptions that hurt most are the ones nobody caught. Wire BugSplat into your global handlers, AppDomain.UnhandledException and TaskScheduler.UnobservedTaskException, so an exception that escapes your try/catch blocks still gets reported instead of vanishing. Unobserved task exceptions in particular are easy to lose entirely, and they're often the ones explaining a bug you can't reproduce.
For console apps, servers, or anything headless where you don't want a dialog popping up, BugSplat can run in quiet mode and report silently in the background.
Why this matters for a lean team
You shouldn't need an observability platform and a dedicated engineer to babysit it just to know which exceptions are hurting your .NET users. Install a package, hook your handlers, and the whole team can see what's breaking, ranked by how often it happens. That's the whole idea: crash and error data that's legible enough to act on, set up by one person in an afternoon.
Full .NET setup is in the docs: docs.bugsplat.com
Want to see your own exceptions grouped and ranked? Start a free trial and post your first one.