Last updated 09 June 2016
Table of Contents
Application-level metrics help developers investigate and diagnose issues with their applications running on Heroku.
Application metrics are only available to apps that are using professional dyno types, which are
performance. Applications using
hobby dynos do not have access to application metrics. Also dynos on legacy pricing plans may not have access to some newer metrics features, such as high-resolution metrics.
To view application metrics, navigate to your app in the Heroku Dashboard and click the Metrics tab. Plot views can be toggled between the default horizontal stacked layout and a compact multi-axes stacked layout. Hovering over a time point on a plot will provide you with the measurement(s) for that time interval.
Individual metrics are gathered per process type.
Values presented in Metrics represent either aggregates of 1 minute windows for the past 2 hours or aggregates of 10 minute windows for the past 24 hours depending on the selected view. For resource utilization values represent maxima or averages per process type.
Metrics gathered for web dynos only
The following metrics are gathered for only the
web process type:
- Median: The median response time (50th percentile) of HTTP requests within the specified sampling interval (10 or 1 minute). This means that 50% of an application’s web requests were completed within less time than the median, and 50% were completed within more.
- 95th Percentile: The 95th percentile response time of HTTP requests within the specified sampling interval. This means that 95% of an application’s web requests were completed within less time, and 5% were completed within more. This is helpful for providing an upper bound (but not maximum) for expected response times.
- OK: The number of successful (status codes < 500) requests serviced per minute. For a 10 minute rollup, this is the total number of successful requests divided by 10 to provide per-minute values.
- Failed: The number of failed (status codes >= 500) requests serviced per minute. For a 10 minute rollup, this is the total number of failed requests divided by 10 to provide per-minute values.
Metrics gathered for all dynos
The following metrics are gathered for all process types, and are averages of the metrics of the dynos of that process type for a given application:
Maximum overall memory usage is displayed as a single stacked plot, combining maximum rss and maximum swap memory as reported for 10 or 1 minute increments. Mean total memory (rss + swap) is shown as a dashed line.
- RSS: The amount of memory (megabytes) held in RAM across dynos of a given process type. Max RSS is reported for each 10 or 1 minute interval.
- Swap: The portion of a dyno’s memory, in megabytes, stored on disk. It’s normal for an app to use a few megabytes of swap per dyno. Higher levels of swap usage though may indicate too much memory usage when compared to the dyno size. This can lead to slow response times and should be avoided. Max swap is reported for each 10 or 1 minute interval.
- Total Memory: Mean total memory represents the portion of memory which user’s can optimize and is shown as the sum of rss and swap as measured in 10 or 1 minute increments and averaged across all dynos.
- 1m Load Average: For 10 minute sampling intervals the mean of the 1 minute load average for each 10 minute period is shown. For 1 minute windows the 1 minute load average is directly displayed. The load average reflects the number of CPU tasks that are in the ready queue (i.e. waiting to be processed) expressed as an exponentially dampened average over the past 30 minutes.
- 1m Load Max: For 10 minute windows this is the maximum value of the 1 minute load average for the time period. For 1 minute intervals the maximum load average from 20 second sampling intervals is displayed.
The Events table contains Heroku errors and user-initiated events that influence application health. Currently tracked user activities include deployments and configuration changes. Additional details are available by hovering over the specific event. These details include error descriptions, and for user-initiated events who made the change and what happened.
The number of errors and events that occurred in the time interval are shown. Critical errors are displayed in red, warning level errors in orange, and informational errors in gray. Activity events (such as deployments and configuration changes) are displayed in blue. Color gradients indicate the relative number of events of each type that occurred during each time interval.
Configuration Variable Change Events
Changes to configuration variables are also captured as events, with the variable that changed shown in the event details.
Deployment Events and Markers
Deployment activities are extended onto the Metrics plots as deployment markers to help users visualize the impact of deployments on application health.
Scaling events are represented as the total number of horizontal and/or vertical scaling activities for the selected time interval.
In addition to raw metrics, Heroku provides online notifications of specific conditions that might be indicative of problems with your application. Links to relevant Dev Center articles are included to provide recommendations on how to correct the problem. Language-specific guidance is provided where available. The list of alerts provided is constantly evolving as we gather more data about application behavior, but examples include alerts on memory errors, request timeouts, and slow response times.
Metrics for App Favorites
24 hour summary web metrics and sparklines are also displayed for each favorited app in the default Heroku Dashboard view. Summary metrics include the total number of dyno and router errors, and the most recent 95th percentile response time and throughput value based on 10 min resolution. Only apps with web dynos will be displayed. Other basic information about your app, including dyno formation/location, most recent deployment, and language, is also shown.