Last updated 14 December 2017
This is an aggregation of the limits imposed on various components of the Heroku platform. It lists only the limits (number of connections, for example) not the features (this database plan has that capability).
Limits exist for several reasons. Sometimes limits are present because of how the underlying platform is constructed: for example, Heroku stores only 1500 lines of log history (the rest being available via a logging add-on). Sometimes limits are present because they enforce good citizenship: for example, you can’t make more than 4500 API requests an hour.
Each limit here is documented with a link to the source document that documents the limit, and which provides a lot more context to the limit.
Heroku allows unverified accounts to run only one build at a time across all their apps.
Heroku only stores the last 1500 lines of log history. If you’d like to persist more than 1500 lines, use a logging add-on or create your own syslog drain.
You can have up to 5 drains on any given app.
Lines generated by dynos that exceed 10000 bytes are split into 10000 byte chunks without extra trailing newlines. Each chunk is submitted as a separate log line.
HTTP requests have an initial 30 second window in which the web process must return response data (either the completed response or some amount of response data to indicate that the process is active). Processes that do not send response data within the initial 30-second window will see an H12 error in their logs.
After the initial response, each byte sent from the server restarts a rolling 55 second window. A similar 55 second window is restarted for every byte sent from the client.
If no data is received from the dyno within the 55 second window the connection is terminated and an H15 error is logged.
Similarly, if no data is received from the client within the 55 second window the connection is terminated an an H28 error is logged.
HTTP response buffering
The router maintains a 1MB buffer for responses from the dyno per connection.
HTTP request buffering
When processing an incoming request, a router sets up an 8KB receive buffer and begins reading the HTTP request line and request headers. Each of these can be at most 8KB in length, but together can be more than 8KB in total. Requests containing a request line or header line longer than 8KB will be dropped by the router without being dispatched.
Different dyno sizes offer different amounts of maximum RAM:
- free, hobby and standard-1x have 512MB
- standard-2x has 1024MB
- performance-m has 2.5GB
- performance-l has 14GB
Dyno memory and restarts
If the memory size of your dyno keeps growing until it reaches two times its quota (for a standard-1x dyno, 512MB x 2 = 1GB), the dyno manager will restart your dyno with an R15 error.
Attached one-off dyno timeout
Connections to one-off dynos will be closed after one hour of inactivity (in both input and output). When the connection is closed, the dyno will be sent SIGHUP. This idle timeout helps prevent unintended charges from leaving interactive console sessions open and unused.
Detached one-off dyno timeout
Detached one-off dynos are cycled every 24 hours. As a result, a one-off dyno will run for a maximum of 24 hours
Concurrent one-off dynos
There are different limits that apply depending on whether the Heroku account is verified or not.
If the account is not verified, then it cannot have more than 3 one-off dynos of type
hobby running concurrently. Accounts that aren’t verified can’t create one-off
standard or one-off
For verified accounts, no more than 5 one-off dynos of each performance dyno size can run concurrently (e.g., 5 performance-m and 5 performance-L).
Standard-1x and standard-2x have a limit of 50 concurrent one-off dynos.
Contact sales to raise this limit for your application.
Config var data (the collection of all keys and values) is limited to 32kb for each app.
The web process in a dyno may not take more than 60 seconds to bind to its assigned $PORT.
Contact support to increase this limit to 120 seconds on a per-application basis. In general, slow boot times will make it harder to deploy your application and will make recovery from dyno failures slower, so this should be considered a temporary solution.
When a dyno is killed or restarted, the processes within the dyno have 30 seconds in which to exit on receiving a SIGTERM. The process is sent SIGKILL to force an exit after this 30 seconds.
Dyno restart limits
hobby dyno types only support a maximum of one dyno running per process type. Additionally, applications using a
free dyno type are limited to a maximum of two concurrent running dynos.
By default, all applications are limited to 100 dynos. Additionally, a process type can’t be scaled to more than 10 dynos for
Contact sales to raise this limit for your application.
Processes / threads
The maximum number of processes/threads that can exist in a dyno at any one time depends on dyno type:
standard-1xdynos support no more than 256
private-sdynos support no more than 512
private-mdynos support no more than 16384
private-ldynos support no more than 32768
These limits include all processes and threads, whether they are executing, sleeping or in any other state. Note that the dyno counts threads and processes towards this limit. For example, a
standard-1x dyno with 255 threads and one process is at the limit, as is a dyno with 256 processes.
The uncompressed size of a checkout of
HEAD from the repo, combined with the size of restored submodules, cannot exceed 1 GB.
Your slug size is displayed at the end of a successful compile. The maximum slug size is 500 MB; most apps should be far below this limit. Once a slug size reaches 300 MB we will warn about larger slug sizes having the potential to cause longer boot times.
Slug compilation is limited to 15 minutes.
Dataclips row limits
Dataclips may return up to 100,000 rows.
Dataclips query limit timeout
Dataclips will cancel queries after 10 minutes.
Hobby, Standard, Premium, and Enterprise tier limits
The limits associated with each Postgres plan tier are described in the Choosing the Right Heroku Postgres Plan article.
Heroku API limits
Calls to the Heroku API are limited to a rate of at most 4500 calls per hour.
Organization memberships are limited to:
- 25 members for non-enterprise accounts
- 500 members for enterprise accounts
Maximum number of applications
Unverified accounts can create at most 5 apps. Verified accounts can create no more than 100 apps.
Maximum number of SSH keys
All accounts may have a maximum of 50 SSH keys associated with their accounts. If you need more than this you should look into using the Build API.