Full post here: judoscale.com/blog/priced...

That looks really cool! (FYI @jeffmorhous.bsky.social)

Here's our write-up on the WHY and HOW of this whole goofy experiment.

judoscale.com/blog/rails-...

That’s where proactive autoscaling comes in. By targeting, say, 60% utilization, you’re building in 40% headroom for unexpected spikes. You’re trading efficiency (and some cost) for reliability.

🧠 More on the differences and trade-offs: judoscale.com/blog/introd...

When budget is tight Fly is definitely the way to go! Glad the calculator was helpful!

Python task queue pro-tip: Autoscale based on queue latency, not CPU!

Your task queue can back up without CPU spikes, leaving you in the dark.

Check out Jeff's full Celery & RQ comparison here:
judoscale.com/blog/choose...

This behavior is confusing at first, but it's actually super cool once you wrangle it.

And with autoscaling in place, we don't really need to worry about it. New machines are being created with fresh burst balances when needed, spreading the load allowing balances to rebuild.

But why do they perform so well at first, only to fall apart after a bit?

It's the bursting!

Shared machines have a "burst balance" where they can use 100% CPU. Once the balance is depleted, CPU is throttled to 1/16.