Rails Autoscale lets you configure how and when your dynos are autoscaled.

When you install Rails Autoscale, autoscaling is disabled by default. When autoscaling is disabled, the settings described on this page will have no effect. Once enabled, Rails Autoscale will begin triggering autoscale events based on these settings and the metrics collected from your app.

You can disable autoscaling at anytime, and your app will no longer be affected in any way by Rails Autoscale. Rails Autoscale will continue collecting metrics from your app, which you can view on the dashboard.

Thresholds are the triggers that cause autoscale events. The queue time metrics you see on your dashboard are continuously compared with the threshold values you specify.

Note that web request queue times in Rails Autoscale are all 95th percentile measurements. This means you can't directly compare the Rails Autoscale metrics with an average metric you might see in New Relic or Scout.

If your queue time exceeds your upscale threshold, your app will be upscaled immediately.

Downscaling is a bit more complicated. To avoid repeatedly scaling up and down, Rails Autoscale does not immediately downscale when your queue time dips below your downscale threshold. Instead, your queue times must remain below your downscale threshold for 10 minutes (you can configure this in advanced settings) before your dynos are scaled down.

There's no magic formula here. The best approach is to start with the default thresholds provided by Rails Autoscale and watch your app's behavior.

If your app is not scale up when you expect it to, try decreasing the upscale threshold. Keep in mind that maybe you were just over-scaled to begin with, and you don't need as many dynos as you thought you did.

If your app is scaling up when you believe there is not a capacity issue, try increasing your upscale threshold.

If your app immediately scales up after scaling down, you're either upscaling too aggressively or downscaling too aggressively. Try increasing your upscale threshold or decreasing your downscale threshold.

Rails Autoscale will only autoscale your app within the range you specify.

Many customers want a minimum of two dynos running—even at very low traffic times—as a form of redundancy. This is entirely up to you. It is generally safe to have a single dyno running if you have autoscaling in place.

The upper limit of your autoscale range is largely based on financial constraints. What is the most dynos you're willing to pay for to avoid an app slowdown?

This upper limit is also constrained by your Rails Autoscale plan. For example, the Silver plan supports a maximum of 9 dynos. This means you cannot set an upper limit beyond 9. If you need the ability to autoscale beyond that, you'll need the Gold plan.

Rails Autoscale can notify Slack every time it autoscales your app. This can get pretty noisy, so it's best to have a dedicated channel for this sort of thing.

If you need more customized scale notifications, it's best to set this up in a logging tool such as Sumo Logic. Since Heroku logs every change to dyno formation, you would search for a pattern like this in your logs:

app api - - Scaled to console@0:Standard-1X rake@0:Standard-1X release@0:Standard-1X web@5:Standard-1X worker@8:Standard-1X by user rails-autoscale@addons.heroku.com

These basic configuration options are sufficient for most apps. If you need more fine-tuning for your autoscale behavior, check out the advanced settings.