Owning your server stack shouldn't be a source of anxiety. Unfortunately, it often is, especially if you only pay attention to the problems you can feel in your gut: Is the app running? Is it throwing exceptions? Does it seem fast enough? These are great intuitive measurements, but just as a doctor uses diagnostics to catch high blood pressure before it becomes a crisis, you need deeper visibility to detect memory leaks, CPU spikes, and disk consumption before they bring your project to a halt.
Hatchbox and AppSignal give you that "deeper visibility." They simplify infrastructure management by replacing manual monitoring with automated, real-time feedback. Together, they transform complex data into actionable insights and make server management accessible to any developer. This gives you the diagnostic depth you’d expect from a much larger operation, without the overhead cost.
What AppSignal Captures at the Host Level
Hatchbox is built to coordinate and manage your Ruby on Rails servers, providing high-level observability for your cluster. To offer greater insights, it has teamed up with AppSignal through a seamless integration. This partnership takes you from manual dashboard monitoring to automated instrumentation, historical trend analysis, alerting, and in-depth metrics all within the context of your application.
When you add the AppSignal gem to your app, you get access to both APM (Application Performance Monitoring) measurements and server-level instrumentation. This includes load average, CPU/memory usage, network traffic, and disk I/O. The table below breaks down how these two layers of visibility work together:
Unlike other services, AppSignal doesn't require a separate tool or daemon; everything is built into the AppSignal gem. The Hatchbox integration enables you to connect your stack in just two clicks, after which you can view real-time insights within Hatchbox or jump directly into AppSignal to debug.
Reading the Host Dashboard
To see the host-level measurements captured by AppSignal, you'll need to navigate to the Host metrics page first. You can find that navigation item under Host monitoring. Once there, click the specific host you're interested in. Alternatively, you can click the specific host listed under the Worst 10 hosts by section within the Overview dashboard.
The Host metrics dashboard displays several charts. These can be broken down into groups: Memory, CPU and load, Disk usage, and Network traffic. Let's take a closer look at each.
Note: Host metrics are only available for apps deployed to a server.
Memory
Ruby is a memory intensive language, and Rails is not the leanest framework.
Even before it handles its first request, a base Rails application with standard boilerplate can easily consume 100 MB to 150 MB of RAM at boot. This makes memory utilization one of the primary measurements to keep an eye on.
In general, a healthy server runs between 40% and 70% memory utilization (used / total * 100.0). When you’re looking for a "normal" memory picture for Hatchbox managed servers, don’t expect to see a flat line. It’s more of a waveform. You'll see peaks during times of high traffic and valleys during low-usage periods. You'll also notice regular drops in memory as Ruby's garbage collector frees up unused memory.
As you continue developing your app (and as you attract more users), you'll notice "used memory" slowly start to increase. This is referred to as "drift," and you won't be able to see it unless you expand your time-frame to the 30-day view.
This drift shouldn't be confused with a memory leak. It’s caused by organic data growth or adding dependencies. Leaks, on the other hand, tend to look like a gradual increase in memory over a shorter time period. While memory usage may drop with traffic usage, the "floor" will continue to grow every day.
Another thing to note: If you see memory climb steadily and then suddenly "crash" to a low point before climbing again, this may signal a process (like a Sidekiq or Resque worker) crashing and getting restarted by the OS or Hatchbox after hitting a limit.
CPU and Load
It's not uncommon to view CPU and load averages as the same thing, but they are actually not. A great way to look at these differences is with a doctor's office analogy. CPU usage would be the speed at which a doctor is able to see patients. Similarly, load average could be imagined as the number of people sitting in the waiting room.
- A load of 1.0 on a 1-core machine means the cashier is busy, but there is no line.
- A load of 2.0 on a 1-core machine means the cashier is busy and there is another person waiting their turn.
Spikes in CPU and load don't always indicate a problem. Often, they show a process kicking off. For example, it's not uncommon for your CPU to max out during the assets:precompile step of a deploy. Likewise, worker restarts may cause a jump in CPU usage and load as it retrieves and starts working on a new batch of jobs.
Disk Usage
When memory, CPU, or load averages spike, your users will experience degraded performance and slower response times. However, if disk usage spikes, they experience a cessation of all activities. Disk usage of 100% on your server means databases can't write recovery logs, temp files can't be created for uploads, and the operating system itself often locks up.
When you're alerted in the middle of the night because of a server crash, these are the three things to look for:
- Logs (the usual suspects): Even when you're rotating logs, a "noisy" app can generate gigabytes of text faster than the rotation script can clean it up.
- Temp files (
/tmp): Image processing and file generation usually happen in the background. Processes such as Resque and Sidekiq can quickly fill up the/tmpand leave no trace of a problem after the server restarts. - Database WAL segments: Both Postgres and MySQL write changes to a WAL file before updating data. There are some instances where a replica loses connection and these segments pile up until the disk is full.
As a rule of thumb, treat 80% disk usage as your warning signal to start investigating. Once you cross 95%, the operating system loses the overhead it needs for routine tasks, potentially leading to a silent yet total failure.
Connecting Host Metrics to App Problems
A measurement by itself is just a number. For it to provide value and help you make good decisions, it needs to be correlated and compared to other data. When taken alone, measurements such as CPU %, memory usage, and disk usage are known as “vanity metrics.”
Vanity metrics might make you feel good, but they don’t change how you act. Actionable metrics change your behavior by helping you pick a course of action.
Although you can use the Host metrics page to compare measurements, it's worth your while to set up a custom dashboard and display measurements either within the same chart or next to one another.
Below, you’ll find a metric correlation cheat sheet:
Alerts Worth Setting Up
A dashboard is only useful while you're looking at it. To stay ahead of issues, you need automated notifications. AppSignal’s Anomaly Detection handles this by alerting you the moment metrics exceed your set thresholds. Setting up these alerts is covered in How to Monitor Your Host Metrics Automatically. For now, these are the triggers you'll want defined for any Hatchbox setup:
- Disk usage: You should set up a warning for 80% and a critical alert for 95%.
- Sustained memory usage: Set this for 80% usage sustained for 5-10 minutes. If your app stays above that threshold, it's likely "swapping."
- Load average anomaly: Define this as a 15-minute average that exceeds your server's core count + 1 (for example, set it for 3.0 on a 2-core server)
Wrapping Up
Monitoring your application's performance without looking at the host is like checking a patient's temperature but ignoring their pulse and breathing. APM tells you what is slow, but host metrics tell you why. Is it the disk at capacity? Is there a memory leak? Is the CPU undersized? Observability is about more than just keeping the lights on. It's about understanding the environment your code lives in.
Hatchbox makes deployment easy, but the responsibility for server health still rests with you. Leveraging AppSignal’s host-level instrumentation lets you keep your finger on the pulse of both your application and the infrastructure hosting it. However, visibility is only the first half of the equation; you cannot spend your entire day watching graphs. By setting up alerts, you move from reactively “firefighting” to proactively managing your stack.