Judoscale Changelog

Autoscaling down to zero instances is a great way to avoid wasteful spending on worker services that often sit idle.

We’ve always allowed Heroku worker processes to scale to zero, and now you can do the same with your Render worker services. Render doesn’t actually permit “scaling to zero"—instead you need to suspend a service.

Judoscale handles this for you behind the scenes. When scaling a worker service to zero instances, we’re actually suspending it for you. And when we scale back up, we resume the service.

So go ahead and let those worker services scale to zero! You’ll reduce your hosting bill, and Judoscale will make sure they scale back up when needed.

Render recently launched projects and environments as a way to organize your services (similar to “apps” on Heroku). Now you can link these project environments to Judoscale.

Judoscale will link all of your Render services in the chosen project environment.

Not only does this keep your Render services organized in Judoscale—it also opens up our existing maintenance mode feature to Render users.

Note that you can no longer link “ungrouped” Render services to Judoscale.

Continuing the improvements to our setup & onboarding, we are introducing the option to change workers autoscaling to use queue depth, i.e. the number of jobs in any given queue (or set of queues).

By default, Judoscale will start with job queue time, our recommended way to autoscale. However, some backends may not support collecting queue time (in which case we will already use queue depth), and some workloads may be better off autoscaling via queue depth. So, after the adapters have been setup and we start collecting metrics, you can jump back on the Setup and choose to switch your base autoscaling metric: (provided that the adapter supports collecting both.)

You can switch between queue time and queue depth at any point in time, just make sure you adjust your autoscaling target ranges accordingly.

Learn more about queue depth autoscaling in our docs.

Building on top of our redesigned scaling schedules, we’ve now made it possible to scale a process based only on schedules.

In most cases Judoscale supports autoscaling based on metrics like queue time, and you can use schedules in combination with that. Sometimes we may not have an adapter to collect metrics for a language / framework, and it is now possible to scale such processes with schedules, for example to lower the number during nights and weekends, while keeping more running during business hours.

If a process supports metrics for autoscaling, you can still choose to set it up first with scaling schedules only. That’s a good way to get started quickly.

You can go back to the setup to review the instructions at any point, or enable metrics based autoscaling later if support is available.

Head to our docs on scaling schedules to learn more.

Our scaling schedules finally got some much-needed attention! Schedules can be super useful for ensuring a higher minimum scale during busy times and pre-scaling for expected traffic spikes. Now you can set up your schedules in a familiar calendar interface.

Edit your scale ranges by clicking anywhere in the calendar, and create new ones with the plus button.

If you were already using schedules, you’ll see the new UI starting today. If you’re not using a schedule, use the “create schedule” button to get started.

Learn about creating schedules in our docs! →

We’ve expanded the setup workflow when onboarding a new Heroku app, to allow starting with response time metrics for autoscaling, even if we have an available adapter to collect queue time metrics. This can be useful if you’re having trouble setting up the adapter initially (we can help!), or just want a quicker way to get started.

You’ll also find a new “Setup” option within the autoscaling settings to relaunch the setup flow. You can check the language and framework settings, and review the adapter installation instructions for them. This helps setting up new types of processes, like a new background worker. And if you’re on Heroku, it’s where you’ll be able to switch your web dyno to autoscale with queue time by installing the adapter with the provided instructions, if you’ve started with response time. (or vice-versa, should you wish.)

We changed how we aggregate response time metrics in Judoscale. Previously we calculated an average response time every 10 seconds, and we’re now calculating a median response time every 10 seconds.

We’ve been exploring this data for several weeks, and we’ve found the median to be a better representation of overall capacity. It’s less prone to being skewed by one or two slow web endpoints which made the average response time more “spiky”.

Note: this does not affect apps using queue time metric, reported from Judoscale adapters.

We’ve added two new controls for tweaking the behavior of your autoscaling: Upscale Sensitivity and Downscale Jumps:

Upscale Sensitivity

Do you see occasional blips of high queue time that only last for a moment before immediately resolving itself?

Now you can extend the sensitivity beyond the default of 10 seconds (that’s the minimum granularity of our metrics). Choosing 20 or 30 seconds will wait until queue time remains above your threshold for that duration of time before scaling up.

Downscale Jumps

This control is most useful for job queues when you want to maximize reduction in resource costs. If you’re often scaling way up to plow through a large job queue, you might want to speed up how quickly you scale back down after you’ve cleared the queue.

That’s when you might want to turn up your Downscale Jumps:

We’ve gotten several requests over the years for a feature that would shut off autoscaling for an entire app at once, temporarily. We’ve taken to calling this simply, ‘Maintenance Mode’, and we’re excited to announce that it’s now available! Maintenance mode will automatically scale worker processes down and prevent any autoscaling on web processes —exactly what most applications need at those times.

Learn more →

The keen-eyed among you might’ve noticed our new logo! After more iterations than we care to mention, we finally settled on a recognizable little character to represent the Judoscale name 😎

You’ll see this new branding all over our site, app, and other assets! After settling into the name “Judoscale” over the last couple of years, we felt like we wanted to add a little personality to our brand.

We also took a bit of time in the last few weeks to redesign our blog:

Where we now highlight a few impactful posts we’ve written over the years and are trialing some side-by-side scrolling. Sparkly ✨