We're happy to announce that we've added a feature that will enable you to create folders for your custom metric dashboards.

During the last few months, we've been working hard on improving our Node.js integration. We've released loads of quality fixes and improvements to our diagnose command, configuration, and general package structure. Today, we'd like to highlight some of the enhancements and fixes that we've recently released.

In the first of this two-part series, we covered how to set up AppSignal in a Ruby on Rails application for many great insights out of the box. AppSignal can automatically track errors, monitor performance, and report metrics about some dependencies. But, in many cases, each of our applications behaves in different ways, so we'll want more than just generic monitoring. In this post, we will run through adding custom instrumentation and monitoring to a Ruby on Rails application.

You can now share any graph from AppSignal with your team, company, and the world. Click the export icon in the graph header to create a hosted image that you can link, embed, or download for further annotation. Developers often share performance screenshots with each other. Some screenshots end up on Twitter where developers explain how they improved their application’s performance with AppSignal. We regularly take screenshots of our graphs as well.

When it comes to monitoring your Elixir application, it's challenging to make sense of the many metrics and statistics that you can read from the internals of the Erlang virtual machine. In this post, we'll be looking at the scheduler utilization metric in order to understand what it is, why we should monitor it, and how to monitor it.

When running and maintaining an application in a production environment, we want to feel confident about the behavior of the application and know when it isn’t working as expected. At the least, we want to track errors, monitor performance, and collect specific metrics throughout the application.

AppSignal users will immediately notice that we’ve updated our product navigation. The new navigation is simpler, cleaner, and improves usability for (power) users. Let’s dive into these changes, along with some background on our philosophy of designing for developers.

Our front-end JavaScript library has been updated with an easier way to add more metadata to front-end errors using the sendError and wrap helpers. Previously, sendError and wrap helpers only supported customizing tags and the namespace for the error. More information could be set on error spans if they were manually created, but now that type of information can be added to errors sent using these helpers.

Good news for Node.js developers using AppSignal: a new version of our Node.js library is available on npm with improved error tracking. We’ve added two new helpers to make your life easier as a Node.js developer. One helper allows you to track errors whenever you need to, no matter how many nested spans you have in your current context. The other lets you send an isolated error with no spans or context involved (for more information about spans, check out our docs).

In this post, we’ll show you what atoms are in Elixir, why you should monitor them, and how to do so with AppSignal. Let’s prevent your app from crashing with a pop up of an error such as.