Follow the steps below and you'll be up and running with BugSplat in no time. If you'd like a full tour of BugSplat and all of its features check out the demo account.
By the end of step 3 you’ll be up processing real crash data
By the end of step 6 your team will be smiling and fixing bugs faster than ever
If you have any questions please reach out to firstname.lastname@example.org.
Take 10-30 minutes on each step per day to get set up in a week, or be an overachiever and knock through all of them in a couple of hours.
First things first, let's create a place to put the crashes you'll soon be sending to BugSplat. In BugSplat, crashes are organized by database. In order to start using BugSplat you'll need to create a database.
When choosing a database name, you should pick something that is descriptive and easy to remember. Please note that spaces, periods, and symbols other than _ are not allowed. Some examples of database names are: DeliciousDonutsApp or Super_Strong_Coffee_App.
To create your first database visit the Database page.
After you've created your database, it's time to post your first crash! It doesn't matter which platform you've chosen to integrate with first, getting a crash with function names and line numbers is a step in the right direction.
Most of our SDKs have a sample application that can help you to quickly post example crash data to BugSplat. All sample applications include multiple ways to force a crash and their crash reports can be compared to your own to test that you've configured BugSplat correctly.
Modify the sample application so that crash reports are posted to your database, rather than our public 'Fred' database. Build and run the sample to post a crash.
The test crash will show up in your Dashboard, and on the Crashes page. Crashes are grouped by their stack key on the Summary page. (The name of the function that caused your crash, along with the filename and line number, is called the stack key.)
If any of these terms are new to you, check out BugSplat's Key Concepts.
It's time to begin processing crash data from your application! Integrate BugSplat in a unreleased version of your application, and force a crash in some way. Creating a hidden mechanism that allows you to test out BugSplat is always a good idea. You should get crash data that is very similar to what you found with our sample application.
Invite a friend, colleague, or trusted teammate to help you test and work through your crashes. BugSplat is built to help teams collaborate on fixing their bugs - what better way to find and fix bugs than with a few of your teammates by your side?
Add access to your BugSplat database via the Users page. Just enter the emails of the team members you want to include in this project. Existing users will immediately gain access. Users without a BugSplat account will receive an email that will guide them through creating an account.
BugSplat plays nicely with many of your favorite apps. Here are a few integrations we offer and how you’ll find them useful:
Slack: One of our most popular integrations and an essential for any team who uses Slack. It brings in alerts about when your crash rates hit a certain level or when a new type of crash is reported. Customizable and powerful - it's a critical integration.
Email: Get alerts sent to you via email for all the same things you see in the Slack integration.
We're always building upon and expanding our tool integrations. If you have a tool you want us to integrate with we'd love to hear about it. Please send a note to email@example.com.
Now that you've set up your application with BugSplat you'll begin to get alerted to new issues that need your team's focus to diagnose and fix. This is easier when you integrate BugSplat into your workflow.
Nearly all applications ship without fixing every known bug. The secret to fast bug fixes and a low crash rate is the ability to determine the scope of an issue. Why? You can resolve issues first that are having the most significant impact on stability, quickly decreasing how often your code is crashing. And you can confidently ignore crashes that don't affect many users.
Use the Summary page to see how often a crash is actually happening to determine if it's crucial to fix based on its volume.
Dive into the Crash page to see how to fix the underlying problem based on its stack trace.
Once you've determined a crash needs to be fixed, create an issue in your defect tracking system directly from a crash report. The crash and all the relevant details will be logged in your issue tracker where it becomes a part of your regular workflow. Best of all, this new issue will have crash specific data that will help take the issue from IN PROGRESS to DONE.
Once you've pushed a fix, you can see if it has solved the underlying problem by tracking the crash in new versions of your application.
Finished with the steps in this guide? Use our Documents to answer further questions about getting the most out of BugSplat, troubleshooting, pricing, and more!