Linux is where crash reporting gets quietly hard. Your users are on distributions you've never installed, with library versions you didn't test against, on hardware you've never seen. A core dump on a machine you can't access does you no good. You need the crash to come to you, already turned into something you can read.
BugSplat does that on Linux the same way it does everywhere else: a small handler catches the crash, ships a minidump, and we symbolicate it into a real call stack with function names and line numbers. The dashboard groups it with every other report of the same fault, so you're triaging problems, not individual incidents.
The Linux-specific gotcha: build IDs and symbols
Two things will determine whether your Linux reports are readable, and both happen at build time.
First, build with symbolic information. If you're using clang++, that means the -g flag. Second, and this is the one people miss, pass -Wl,--build-id so the linker stamps a build identifier into your executable. BugSplat uses that build ID to match a crash against the right symbols. No build ID, no reliable match, and your stack traces come back as addresses.
Then you generate and upload .sym files. BugSplat's symbol-upload tool will generate and upload them in a single command, which is the path we'd point you toward, it's one step in your build pipeline instead of a manual dance with dump_syms and symupload separately. Re-upload on every build, versioned. Symbols that don't match the binary that crashed are the number one reason a report comes back unreadable, on every platform, and Linux is no exception.
How the integration works
Native Linux apps integrate through Crashpad, which builds for Linux with a C++ compiler plus build-essential and libcurl4-openssl-dev. You ship crashpad_handler with your application, point it at your BugSplat database URL, and make sure the directory it writes reports to is actually writable, or the handler itself will crash, which is a fun afternoon to debug. Our myUbuntuCrasher sample has a working build script you can crib from, including the clang++ link line with the symbol and build-id flags already in place.
If you're building a server-side application, the same approach applies. Crashes from a Linux server land in the same dashboard as everything else, which matters if you're running both client and dedicated server builds and want one place to watch them.
Why it's worth doing right
The Linux user who crashes is, almost by definition, on a configuration you didn't test. That's not a reason to fly blind. It's the exact reason to have crash reporting that reaches across every distro and kernel and hands you a readable stack trace from a machine you'll never touch. One person sets it up. The whole team reads the results.
Full Linux setup, including the symbol-upload tool, is in the docs: docs.bugsplat.com
Want to try it on your own build? Start a free trial and submit your first crash.