ECS Autoscaling that worksusing queue time instead of CPU or memory
Explore for yourself in our sandbox app →
“The first step to a scalable web service is automatic autoscaling. Without autoscaling, you're just waiting for a flash sale, social media post, or other "white swan" event to take down your site at just the wrong moment. ”
Queue time, not CPU or memory
Amazon ECS autoscaling—based on CPU and memory—is inconsistent and unreliable. Queue time is the true measure of task capacity, and Judoscale is the only autoscaler for ECS that uses it.Learn more about request queue time →
Web services and background tasks
Queue time isn’t just for web services. Judoscale also uses queue latency to autoscale your background tasks, ensuring your job queues never back up.
Faster and more reliable than Amazon ECS’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 Amazon ECS compute costs
Your ECS tasks are probably overscaled, and Judoscale can help. Our autoscaling algorithm is more efficient than ECS’s, allowing you to 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 tasks at a time and tweak the frequency of scaling. Each task 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 AWS application?
Sure, let’s talk! Use this link to book a call with us.
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!
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.
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.
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 could see the care in Judoscale’s documentation, the gems were well-documented and designed with a general sense of quality.
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