Understanding Judoscale Adapter's Performance and Compatibility

What is the Performance Impact of the Judoscale Adapter?

The adapters have no noticeable impact on response or job time. They collect the queue time for each request or job in memory — a very simple operation — and an async reporter thread periodically posts those queue times to the Judoscale back-end. Check out the middleware code on GitHub if you’re interested.

Can I use other autoscalers with Judoscale?

You can use different autoscalers for different dynos. For example, you could use Heroku’s native autoscaling for web dynos and Judoscale for worker dynos.

Do not use multiple autoscalers on the same dynos, though. This results in very unpredictable scaling behavior.

Should I use Heroku’s native autoscaling instead of Judoscale?

It depends on your goals and architecture.

Heroku’s autoscaler is response-time based and only works with performance/private/shield dynos. Judoscale also supports response-time autoscaling, but we generally recommend queue-time autoscaling when possible because it tends to be more reliable for apps with a mix of fast and slow endpoints.

If you’re comparing the two options, a common approach is:

• Pick one autoscaler per process type (never both on the same process).
• Temporarily disable autoscaling for that process in Judoscale.
• Enable Heroku autoscaling for the same process and compare behavior over a few traffic cycles.

As for a direct comparison between the two, here’s what Judoscale offers over Heroku’s native autoscaling:

• Web autoscaling uses request queue time instead of response time.
• Worker autoscaling is only possible with Judoscale.
• Standard dyno autoscaling is only possible with Judoscale.
• Autoscaling is triggered within 30 seconds, not several minutes later.
• Judoscale offers many controls to customize autoscaling behavior.
• Clear visibility into scaling and the metrics that trigger it.
• One-on-one support with the devs who work on the product.

Can I pause Judoscale without uninstalling it?

Yes. You can disable autoscaling for a specific process in Judoscale and leave the integration installed.

Judoscale will keep receiving metrics while autoscaling is disabled, so you can re-enable it later without reinstalling anything.

Can I get an alert when a process wants to scale up but is already at max dynos?

Not exactly. We don’t currently send a notification at the exact moment a process would scale up but can’t because it already hit your configured max.

We do send an automatic notification if a process reaches max scale and stays there without downscaling for a sustained period (currently about six hours). That alert is built-in and not configurable at this time.

If you frequently run near max dynos and see user-facing slowdowns, the quickest mitigation is usually to raise the max by one dyno (if your plan and platform limits allow) so Judoscale has room to respond.

Can I export Judoscale metrics to another tool?

We don’t have a public metrics API yet, but it’s on our roadmap. If you need to correlate queue time with other telemetry today, the Judoscale middleware exposes queue time via the Rack environment, so you can forward it to your logging or observability stack alongside your existing data.

What data does Judoscale collect from my app?

Each adapter periodically sends queue-time metrics to the Judoscale back-end so we can aggregate them and apply our autoscaling algorithm. Alongside those metrics we collect a small amount of metadata (language, framework, adapter version, and basic configuration) to make sure we interpret the data correctly. We never transmit job arguments or request bodies—only queue-level measurements—so sensitive payload data stays in your app. All adapter packages are open source, so you can review exactly how those metrics are produced before installing them.

Can I run Judoscale without sending data to Judoscale servers?

No. The autoscaling configuration and logic run on Judoscale’s infrastructure, so we need the metrics reported from your app to make scaling decisions and call the appropriate platform APIs. There isn’t an airgapped or isolated mode available today.

Is Judoscale useful for low-traffic hobby apps?

As your project starts to get traffic, Judoscale helps you scale your web and worker services automatically so you don’t have to decide how many instances to run.

For low-traffic hobby projects, Judoscale usually won’t do much for web services yet. One exception: if you run background workers, you can use Judoscale to scale those workers to zero when idle and save money.

Can Judoscale support my hosting platform?

Sometimes yes, but not always right away.

We prioritize new platform integrations based on overall customer demand, and we usually only ship support after we have hands-on experience running workloads on that platform ourselves. That extra time helps us discover sharp edges and support teams well once an integration is live.

If your platform isn’t supported yet, you can still autoscale with our Custom API integration today.