You can now pause autoscaling for an entire app, for a set time or until you resume it. Your processes stay at their current scale, which is handy during load tests, incidents, or deploys that may cause unexpected scaling.
Pause from your app’s settings, next to maintenance mode. It’s also available in the Team API and the CLI.
Carlos Antonio da Silva
Back in May we added a per-instance view to the web Queue Time and Response Time charts. Now you can break down more of your charts: web Throughput and Utilization can show each dyno / instance individually, and worker Queue Time and Queue Depth can show each queue.
Click a chart’s label to switch between the combined view and the breakdown, then hover the chart to see each line’s value at that moment, sorted highest first. Viewed together, the web charts make a misbehaving dyno easy to spot: it handles fewer requests while its queue time and utilization climb above the rest.
On worker processes, the combined Queue Time chart shows your slowest queue. The per-queue view shows every queue that process works, so you can see which one is backing up and whether the others are keeping up.
Head to the app to break down your charts.
Adam McCrea
One big spike can flatten the rest of a chart, making smaller changes hard to see. You can now zoom in vertically on your metrics to get a closer look without changing the time range.
Use the slider beside each metric: drag the top handle down to lower the ceiling, or the bottom handle up to raise the floor. Each metric zooms independently, and your chosen range stays put as new data arrives or you change the time range. Return the handles to their starting positions to fit the chart to the data again.
Head to the app to take a closer look at your metrics.
Adam McCrea
The Judoscale CLI is here! Manage your apps, processes, schedules, and autoscaling settings from the command line, and read metrics and scaling history.
brew install judoscale/tap/judo
judo auth login
judo apps list
Output is JSON, so it’s easy to use in scripts. It follows the Team API, and judo update picks up new endpoints and fields without upgrading the CLI.
It’s also built for AI agents. Give an agent its own read-only API token, point it at judo help, and it can look up your apps and scaling history on its own.
We’re also exploring a hosted MCP server for the future.
Carlos Antonio da Silva
We just launched Judoscale for Northflank. Connect a team-scoped API token, link a project environment, and Judoscale can scale the instances on your combined and deployment services. That includes Northflank Cloud and bring-your-own-cloud projects.
Northflank already autoscales on CPU, memory, and requests per second. Those signals tell you how hard the containers are working, not whether requests or jobs are waiting. Judoscale scales on request queue time for web services and job queue latency for workers, so Sidekiq, Celery, BullMQ, and the rest react to backlog. Schedules and per-service controls are included.
Adam McCrea
The Judoscale Team API is here! Manage your team, apps, processes, autoscaling settings, and schedules programmatically. Read metrics, scale events, and restart events for your apps.
Authenticate with a team API token. The docs include an interactive reference and an OpenAPI spec.
Carlos Antonio da Silva
We now support autoscaling Next.js with a dedicated judoscale-nextjs adapter!
This is for self-hosted, long-lived Node (next start or equivalent) on Heroku, Render, Railway, Fly.io, Scalingo, and Amazon ECS. It does not support Vercel serverless or the Edge runtime—those don’t have a long-running process for the reporter.
Setup uses Next’s instrumentation.ts hook, so every request (App Router, Pages, Route Handlers, RSC) is instrumented without framework middleware.
Adam McCrea
We just launched Judoscale for Scalingo, the European PaaS that feels a lot like Heroku. Push your code, get containers and managed databases, and run in Paris datacenters with GDPR, ISO 27001, and HDS certifications built in. If you’re shipping Rails, Node, Python, or Java and want a real PaaS instead of a DIY cluster, Scalingo is a solid home for your app.
Scalingo already supports horizontal scaling and a native autoscaler based on CPU, memory, response time, and traffic. Those metrics are useful, but they’re indirect: they tell you how hard your containers are working, not whether users or jobs are waiting. Judoscale scales on request queue time for web and job queue latency for workers, so Sidekiq, Celery, BullMQ, and friends react to backlog instead of CPU warmth. Schedules and per-container-type controls are included.
Link a Scalingo project, pick an app, and you’ll be autoscaling in minutes. Getting started docs are ready, and if you want the full pitch, visit our Scalingo landing page.
Adam McCrea
Team members now have a role: Member or Admin. Members get full access to the team’s apps and autoscaling. Admins get all that plus managing the team itself — settings, subscription, members, and the new team-wide 2FA requirement.
Admins can require two-factor authentication (2FA) for the whole team in one click. Anyone without it will be asked to set it up at their next sign-in.
Read more in our team management docs.
Carlos Antonio da Silva
We’re rolling Dyno Sniper out to all customers running on Heroku, after running successfully in early access on our own production apps (and a few customers) for some time.
It complements autoscaling by automatically detecting and restarting poorly performing dynos — the kind that get stuck on noisy hardware and drag down your queue time (or response time), even when the rest of your fleet is fine.
Find it under your web process’s advanced settings:
Restarts show up directly above the scale chart. Hover any marker to see which dyno was sniped:
Carlos Antonio da Silva