When developing mobile apps it’s important to monitor errors so that you can understand your user’s experience. You need deeper insight than just a crash report because errors could cause a degraded user experience or a drop in key behavioral metrics. Your team needs to know quickly when there are production problems either with the app itself or with your backend services so you can fix the issue before more customers are impacted.
Rollbar’s Android SDK lets you track and analyze errors that happen in your Android native applications, and even trace problems to backend services and third party APIs. It provides you with a live error feed from your application, including complete stack traces and contextual data to debug errors quickly. We also track the environment the error is coming from (prod or staging), the server that generated the error, and even the user’s session data. You can then quickly assign ownership of errors to your team and track when they are fixed. Learn more about Rollbar’s product features for Android.
Below, you can see that we've created an example app that triggers an exception when the user clicks on a button. The error message is tracked in Rollbar, including a stack trace where you can see the line of code that caused the error. Rollbar captures errors that occur anywhere in the app. You can follow along with our example using the source code on GitHub.
ASP.NET MVC is a modern web development framework that combines the features of MVC (Model-View-Controller) architecture for better separation of concerns and the best parts of the ASP.NET platform.
We’ll show you an example of how to catch errors and exceptions in ASP.NET MVC using a global action filter. We’ll also show you how to track them in Rollbar’s error monitoring service. This will give you real time visibility into your errors in production. It also captures person data and other context from your app so you can solve errors faster.
After fixing a bug, who is responsible for making sure if it really resolves the customer's problem? A lot of companies take a fire-and-forget mentality where the developer makes a code change, and they never think of the problem again until someone complains. Developers often assume that the fix will be deployed with the next release, that the fix will behave the same in production as it does in their development environment, and that it resolves every case uniformly. Only for the most urgent problems will they wait for the fix to hit production and then verify the improvement on the customer's side.
Rollbar offers an impressive array of error alerting and notification options for you to choose from, which is awesome! But sometimes we hear from our users that they aren't quite sure how to leverage their notifications to get the best results. What do notifications here at Rollbar do? How do they work? How should you interpret them? And perhaps most importantly, what are the best practices? Let's explore the answers to all these questions today.
Our friends at Losant wanted to share how they built an actual 'error-alarm' using the Rollbar and Losant API's. Enjoy!
When I envision a tech company's smart office, I see tons of dashboards and indicator lights that monitor everything. Efficient monitoring is a critical piece of today's technology stack, and there are always ways to improve. Rollbar already does an impeccable job at alerting you when errors are thrown in your application. But, to increase awareness, accountability, and awesomeness in the office, we can connect Rollbar to our smart office. In this tutorial, we are going to build an office error alarm powered by Rollbar and Losant.
Some of the most common questions we get here at Rollbar deal with source maps:
Our friends at GorillaStack wanted to share how they set up Rollbar with the Serverless framework, and made a handy tool so you can do the same.
Here at GorillaStack, we are big lovers of the Serverless framework. By default, the Serverless framework uses CloudWatch logs to store any system log messages and output from your lambda code. Pretty quickly, we found ourselves needing to escalate log messages such that we could be notified of application errors and act on them more proactively.
Our friends at Cuttlesoft wanted to share how they use Rollbar to detect errors in Ionic built applications. Enjoy!
At Cuttlesoft, we use Rollbar's excellent full-stack error monitoring service for pinpointing and fixing tricky bugs. Our team loves Rollbar for its integrations with other popular services (we get our error notifications via Slack so we’re constantly in the know). For building hybrid mobile and progressive web apps, we generally rely on Ionic. Ionic is an open-source framework for hybrid mobile app development maintained by Drifty. Built with AngularJS and Cordova, Ionic is a popular tool for mobile developers everywhere. To combine these two, we've developed a method for integrating Rollbar error tracking with the Ionic stack.
Ruby is a popular open source programming language that is highly flexible, and used for everything from basic "hello world" apps to sophisticated, dynamic programs. Whether you've been programming in Ruby for years or you're a complete beginner, tracking down errors in your Ruby app is simple and easy. Let's go through some basic Ruby error handling, and discover how easy it can be to integrate Rollbar into your Ruby app to automatically log and report your exceptions.
Ruby's default exception handling is to terminate the program in the event of an exception. That's not really useful when you're trying to build a complex web application for multiple users. Luckily there's a way around this - declaring exception handlers. Exception handlers are blocks of code that are called if an exception occurs in the execution of another block of code in your program. For the most basic Ruby exception handling, you need to know how to Raise and Rescue an exception.
When you Raise an exception, you stop the normal flow of the program, and execute the code that deals with handling an error. This code can either deal with the error in some way, or terminate the program. If you provide a Rescue clause in your error handler, you can choose how to deal with the exception; without it, the program will simply terminate.
Developing and maintaining user facing software is a challenge and a very distracting one at that. :-) Often times it can be difficult trying to stay focused on what matters most. It can be hard to tell what's really broken and why, with dozens of alerts notifying you every other minute. Volatile... The client-side being one of the most volatile of them all.
You're two weeks into using Rollbar. You've watched in amazement as issue after issue comes in without a single customer complaint to accompany them. How did you ever find errors before!?
Now that your unresolved errors have drastically decreased, you've started to notice a handful of Rollbar items that all seem to be exactly the same issue. Maybe you've been notified that your UI has exceeded the maximum call stack when calling a particular function. And in one case you found out that your database is actually missing several columns which got grouped into a single error.
What's a new Rollbar user to do? Here's 6 steps to help you improve your error grouping in Rollbar:
Below I have outlined a simple guide for setting up source map generation and usage in a sample Django app. You’ll learn how generate source maps for minified files, debug errors that happen in these files, and also a quick overview of what’s required to get this working for your production environments.
Source Maps were designed to resolve this; they provide a mapping back from the minified line/column numbers to the original code. Chrome and Firefox have tools to use them in development, but what about errors that happen in production?