Today, we’re launching a major upgrade that will improve the way yourteam manages application errors, with more error states, error assignments,severity labels and a “my incidents” overview. Your team’s communication around incidents will improve significantly.You’ll know exactly how severe an error is, who’s responsible, and howyou handled this error historically.

We’re launching a new line-of-code based method of grouping errors. Ifyou enable this grouping method in “App settings”, we will find the lineof code that was the source of the error and use that to split out errorsthat otherwise have the same type. To access the feature, upgrade to the latest AppSignal APM for Node.js integration. This is especially useful for Node.js andElixir parts because in these languages different errors often have the same type.

It’s important to be able to look at the entirety of your application architecture, not just specific aspects of it, and understand how different parts connect. Observability comes first, followed by monitoring. In this post, we’ll dive into the database part of your architecture to show how you can monitor and optimize your database performance.

When we were moving an app to Kubernetes, we encountered a peculiar situation where other services running on Kubernetes started throwing a ThreadError from time to time, saying that a resource is unavailable. We started investigating, and it turned out that you want to know where your AppSignal error has occurred. A short reminder - Kubernetes works on two levels: So, you want to know which pod and which node ran a particular AppSignal transaction.

Even if you write the fastest code in the world, you can still be slowed down by external factors. In this post, we will deal with performance monitoring external APIs and how you can prevent these slow APIs from slowing you down.

Tests are an integral part of most well-working Rails applications where maintenance isn’t a nightmare and new features are consistently added, or existing ones are improved. Unfortunately, for many applications, a production environment is where they are put under heavy workload or significant traffic for the first time. This is understandable as such tests are costly.

We recently released uptime monitoring, a pretty big addition to our set of features. Our customers have often requested it, and it was a logical next step for us to add uptime monitoring to our app. In today’s post, we’ll explain how we went from considering uptime monitoring impossible to build, to building it in a week. We’ll break down how seemingly over-engineering can really pay off in the end.

In this post, we’ll do a quick overview of monitoring memory issues in Erlang and Elixir setups. We’ll do so by monitoring memory usage at three levels: Host, OS, and within the Erlang VM.

We’re constantly looking for interesting integrations for our performance incidents, exception incidents, anomaly detection and uptime monitoring notifications, and our latest addition is an integration for Microsoft Teams. Microsoft Teams is a hub for team collaboration in Microsoft 365. It integrates people, content, and tools your team needs to be more engaged and effective.

AppSignal is your one-stop shop for application monitoring. Today, we’re releasing uptime monitoring. Simply add any endpoint you want to check for uptime and AppSignal will monitor it from locations around the globe, 24/7. Uptime monitoring expands our current feature set (error tracking, performance monitoring, metric dashboards, server metrics, and anomaly detection). All features are combined in a beautiful and easy-to-use interface, with a friendly pricing model for developers.