Question
Which dyno size minimizes cost while maintaining acceptable response latency for low-traffic Heroku apps?
Ari Nea
0 reputation · 24 Apr 2021, 04:30 UTC
24.7K views1
Loading…
0 reputation · 24 Apr 2021, 04:30 UTC
Low-traffic Heroku applications consume dyno hours even during periods of nominal inactivity, affecting monthly budgets. A precise goal is to evaluate whether the combination of automatic dyno sleeping after thirty minutes of inactivity and the selection of a minimal dyno size sufficiently reduces costs while preserving adequate request latency for sporadic workloads.
Heroku's documented sleeping behavior pauses dyno billing during quiescent intervals, yet wake-up latency and the influence of custom process types on sleep retention introduce operational uncertainty. The retirement of the free tier in November 2022 means all low-traffic workloads rely on paid dyno tiers, and add-on recurring fees can accumulate unnoticed, potentially outweighing dyno cost savings.
Which balance of dyno size and sleep configuration minimizes total cost of ownership? What idle duration reliably triggers sleep across Standard-16M and Performance-M tiers? Does adding background workers compromise the cost efficiency of sleeping dynos?
26525 reputation · 24 Apr 2021, 15:53 UTC
For a lightly used web app that can tolerate occasional sleep, the Hobby dyno ($7 / month) offers the lowest total cost while keeping request latency acceptable. It runs continuously, avoids the 30‑second cold‑start penalty of the Free tier, and still costs far less than any Standard or Performance dyno.
herokuheroku create --buildpack heroku/nodejs (or your language’s buildpack) and push the repo.curl https://yourapp.herokuapp.com/health) and record the elapsed time.heroku ps:scale web=1 --app yourapp --dyno-type hobby.hey -z 5m -q 1 https://yourapp.herokuapp.com/health.heroku ps:scale worker=1 --app yourapp and check logs for continuous activity.If your application uses background workers, WebSockets, or requires a steady outbound connection (e.g., to a database or external API) that keeps the dyno awake, the Free tier may not sleep as expected. In that scenario, a Hobby dyno remains the cheapest reliable option; otherwise, a Standard‑1X dyno could be justified for predictable performance.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 24 Apr 2021, 16:14 UTC
Heroku’s 30‑minute auto‑sleep is triggered only on web process types. worker or clock dynos stay awake continuously, so any background job will keep the dyno billed even if the web interface is idle.
When you need background processing, add a dedicated worker dyno. Even a single worker on a Hobby dyno costs the same $7/month, but it prevents the web dyno from sleeping because it keeps the app’s process running.
For <1–5 requests per second and tolerable 30‑second cold starts, a Hobby dyno is the cheapest ($7/month). If you require <200 ms latency on the first request or higher concurrency, a Standard‑1X ($25/month) offers the same CPU core but stays awake and adds a small 10–20 ms overhead.
| Dyno | Cost | CPU | RAM | Sleep | Typical Latency |
|---|---|---|---|---|---|
| Hobby | $7 | 1 core | 512 MB | Yes | 50–100 ms (post‑sleep 30‑60 s) |
| Standard‑1X | $25 | 1 core | 512 MB | No | 30–80 ms |
| Standard‑2X | $50 | 2 cores | 1 GB | No | 20–60 ms |
| Performance‑M | $250 | 2 cores | 1 GB | No | 10–30 ms |
Use a Hobby dyno with auto‑sleep for minimal cost if occasional 30‑second cold starts are acceptable. Add a separate worker dyno only when background jobs are required, and consider Standard‑1X if you need consistent low latency for the first request.