Limits

Last Updated: 11 April 2014

Table of Contents

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 1200 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.

Logs

Log history limits

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.

Source

Drains

You can have up to 5 drains on any given app.

Router

HTTP timeouts

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 (either from the client or from your app process) resets a rolling 55 second window. If no data is sent during this 55 second window then the connection is terminated and a H15 error is logged.

Source

HTTP response buffering

The router maintains a 1MB buffer for responses from the dyno per connection.

Source

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.

Source

Dynos

Dyno memory

Different dyno sizes offer differ amounts of maximum RAM:

  • 1X has 512MB
  • 2X has 1024MB
  • PX has 6GB

Source

Dyno memory and restarts

If the memory size of your dyno keeps growing until it reaches five times its quota (for a 1X dyno, 512MB x 5 = 2.5GB) or two times its quota for PX dynos, the dyno manager will restart your dyno with an R15 error.

Source

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.

Source

Concurrent one-off dynos

Heroku accounts that aren’t verified cannot have more than 3 one-off dynos of size 1X running concurrently. Accounts that aren’t verified can’t create one-off 2X or PX dynos.

Source

Config vars

Config var data (the collection of all keys and values) is limited to 16kb for each app.

Source

Boot timeout

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.

Source

Exit timeout

When a dyno is killed or restarted, the processes within the dyno have 10 seconds in which to exit on receiving a SIGTERM. The process is sent SIGKILL to force an exit after this 10 seconds.

Source

Dyno restart limits

Heroku’s dyno restart policy is to try to restart crashed dynos by spawning new dynos once every ten minutes. This means that if you push bad code that prevents your app from booting, your app dynos will be started once, then restarted, then get a cool-off of ten minutes. In the normal case of a long-running web or worker process getting an occasional crash, the dyno will be restarted instantly without any intervention on your part. If your dyno crashes twice in a row, it will stay down for ten minutes before the system retries.

Source

Dyno scale

By default, a process type can’t be scaled to more than 100 dynos for 1X- or 2X-sized dynos. A process type can’t be scaled to more than 10 dynos for PX-sized dynos.

Contact support to raise this limit for your application

Source

Processes / threads

The maximum number of processes/threads that can exist in a dyno at any one time depends on dyno size:

  • 1X dynos support no more than 256
  • 2X dynos support no more than 512
  • PX dynos 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 1X dyno with 255 threads and one process is at the limit, as is a dyno with 256 processes.

Source

Build

Git requests

Users are limited to a rolling window of 75 requests to Heroku Git repos per hour, per app.

Source

Slug size

Your slug size is displayed at the end of a successful compile. The maximum slug size is 300MB; most apps should be far below this limit.

Source

Slug compilation

Slug compilation is limited to 15 minutes.

Source

Heroku Postgres

Dataclips row limits

Dataclips may return up to 29,999 rows.

Source

Dataclips query limit timeout

Dataclips will cancel queries after 10 minutes.

Source

Standard, Premium, and Enterprise tier

Source

Hobby tier

  • Enforced row limits of 10,000 rows for dev and 10,000,000 for basic plans
  • Maximum of 20 connections
  • No in-memory cache

Source

API

Heroku API limits

Calls to the Heroku API is limited to a rate of at most 1200 calls per hour.

Source

Bamboo

The Bamboo heroku.com stack has a 30 megabyte request body size limit.

Source

Other

Maximum number of applications

Unverified accounts can create at most 5 apps. Verified accounts can create no more than 100 applications.

Source