Judoscale Changelog

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 ✨

You can now set your background job processes to monitor “All queues” for autoscaling:

So you no longer need to go through a potentially-long list and click all the queue names. It’s a small thing, but this will be a big quality-of-life improvement for several of our users!

We’re excited to announce another pair of supported frameworks: Bull and BullMQ. The Bull ecosystem is now fully queue-time-autoscalable with Judoscale. We can’t wait for our Javascript clients to start taking advantage of this!

BullMQ is a rewrite of the popular Bull library by the same authors, but with a new API and a more modern codebase written in Typescript and with a bunch of new features and performance improvements.

Autoscale all the job queues! Learn more →