Render Autoscaling that worksusing queue time instead of CPU or memory
Explore for yourself in our sandbox app →
“I was very excited to not see any Pingdom alerts this weekend. We got alerts every morning using Render’s autoscaler, but not with Judoscale. So awesome! ”
Queue time, not CPU or memory
Render’s autoscaling—based on CPU and memory—is inconsistent and unreliable. Queue time is the true measure of server capacity, and Judoscale is the only autoscaler for Render that uses it.Learn more about request queue time →
Web services and background workers
Queue time isn’t just for web services. Judoscale also uses queue latency to autoscale your background workers, making sure your job queues never back up.
Faster and more reliable than Render’s autoscaler
A capacity issue needs to trigger autoscaling as quickly as possible, and Judoscale is the fastest autoscaler available. Our autoscaling algorithm runs every 10 seconds, ensuring your app scales up before users notice an issue.
Reduce your Render compute costs
Your Render services are probably overscaled, and Judoscale can help. Our autoscaling algorithm is more efficient than Render’s, so you can scale down without sacrificing performance or peace of mind.
Customize your autoscale behavior
Every app is different, and so Judoscale gives you complete control over how your app autoscales. You can scale by multiple instances at a time and tweak the frequency of scaling. Each process is configured independently with a few simple sliders.Explore the configs in our sandbox app →
- Trusted by900+engineering teams
- Over2.5 millionautoscales per month
- Since2017we are here to stay
Got questions?
Check out our docs for a whole lot more. If you still can’t find what you’re looking for, send us an email!
What languages and frameworks does Judoscale support?
We support many web frameworks and job/task queues for Ruby, Python, and NodeJS. See the full list in our docs.
What data can Judoscale access in my app?
Our adapter libraries only collect queue-related metrics for requests and job queues along with basic process metadata. No actual request or job data is ever collected.
Can we have a call to see if Judoscale makes sense for our Render app?
Sure, let’s talk! Use this link to book a call with us.
Judoscale’s deep integration with Sidekiq queues let us easily tag which queues we wanted a faster response. We were able to tune our scaling sensitivity for exactly our usage pattern of intermittent batches of large jobs.
Setting up queue-based autoscaling on @render in like 5 minutes thanks to @adamlogic. Used it a few years back on Heroku, was delighted when I discovered they now support Render! Saved me a lot of trouble finagling with Sidekiq and Render APIs and custom scripts.
If I was the king of the world, I would make it illegal to horizontally scale based on execution time. Scale based on queue depths, people!
Chameleon has been extremely stable thanks to Judoscale. We have very high spikes in traffic, and I don’t even have to think about it.
We could see the care in Judoscale’s documentation, the gems were well-documented and designed with a general sense of quality.
Request queue time is the single most important part of this. Scaling by CPU and memory consumption makes no sense—your server should have stable memory usage and nearly 100% CPU utilization.
We’re really impressed by the simplicity and ease of use of Judoscale. We’ve gone from constant worries over site performance, to complete confidence in our configuration. What a great tool!
Start autoscaling for free
Setup takes less than 5 minutes