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.
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.
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.
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.
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:
The Queue Time and Response Time charts now have a per-instance view that shows each web dyno / instance individually. Click the chart label to switch between the average view and the per-instance view.
Hover the chart to view each instance’s value at that moment in time, sorted highest first — handy for spotting if it’s a fleet-wide spike or maybe a specific instance that might be misbehaving.
Head to the app to view your app’s per-instance chart breakdown.
Our charts have always shown date/time stamps using your local (browser-based) time zone, but the schedule has been UTC-based since the beginning. Now both speak the same time zone: yours!
The schedule is now displayed matching the charts time zone, which can be configured in your user settings or directly in the chart overview, so you can choose a specific time zone to see both the charts and schedule across the board. This only affects your view.
The schedule can also be anchored to a specific time zone (UTC by default), and is going to be daylight saving time-aware, so it will adjust accordingly as clocks change. The time zone is set is per-process, so you can have a different one on each process if needed.
Worker process scaling charts now include a “Busy Jobs” row that shows when your background workers had active jobs running.
This row appears when you have the Prevent downscaling when jobs are busy setting enabled, helping you see at a glance when job activity might be preventing downscaling.