There are limits in GitHub Actions which you may hit as you scale up, some may be increased by contacting support.
You may be rate limited by GitHub Actions when you scale your usage. Some limits can be increased by contacting us through the GitHub Support portal.
Unless otherwise stated, the expected behavior when a limit is reached is that the workflow/job will get cancelled.
These limits are subject to change.
| Limit category | Limit | Threshold | Description | Can GitHub Support increase? |
|---|---|---|---|---|
| Workflow execution limit | Workflow run time | 35 days / workflow run | If a workflow run reaches this limit, the workflow run is cancelled. This period includes execution duration, and time spent on waiting and approval. | |
| Workflow execution limit | Gate approval time | 30 days | A workflow may wait for up to 30 days on environment approvals. | |
| Workflow execution limit | Job Matrix | 256 jobs / workflow run | A job matrix can generate a maximum of 256 jobs per workflow run. This limit applies to both GitHub-hosted and self-hosted runners. | |
| Workflow execution limit | Re-run | 50 re-runs | A workflow run can be re-run a maximum of 50 times. This limit includes both full re-runs and re-runs of a subset of jobs. | Support ticket |
| Checks | Check runs per check suite | 50,000 check runs / check suite | A check suite can have a maximum of 50,000 check runs. This limit applies to check runs created through the Checks API and by GitHub Actions workflow runs. When a check suite reaches this limit, additional check runs cannot be created for that check suite. | Support ticket |
| Workflows queuing | Workflow trigger event rate limit | 1500 events / 10 seconds / repository | Each repository is limited to events triggering a workflow run. | Support ticket |
| Workflows queuing | Workflow run queued | 500 workflow runs / 10 seconds | When the limit is reached, the workflow runs that were supposed to be triggered by the webhook events will be blocked and will not be queued. Reusable workflows are viewed as a single entity. For example, a run with 30 reusable workflows counts as 1 in this instance. | |
| Workflows queuing | Concurrency group queue | 100 workflow runs / concurrency group | When using queue: max in the concurrency section, up to 100 jobs or workflow runs can be queued per concurrency group. Runs beyond this limit will be rejected. |
|
| Self-hosted | Runner registrations | 1500 runners / 5 minutes / repository/org/enterprise | Runners can be registered per repository/organization/enterprise. | Support ticket |
| Self-hosted | Runners per runner group | 10,000 runners | Runners registered at the same time per runner group. | |
| Self-hosted | Job execution time | 5 days | Each job in a workflow can run for up to 5 days of execution time. If a job reaches this limit, the job is terminated and fails. | |
| Self-hosted | Job queue time | 24 hours | A job can be in the queue for 24 hours before it is automatically cancelled. | |
| All GitHub-hosted runners | Job Concurrency | Varies | See Job concurrency limits for GitHub-hosted runners. | Support ticket |
| All GitHub-hosted runners | Job execution time | 6 hours | Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails. | |
| All GitHub-hosted runners | Storage limits | Varies | For more information, see Storage limits for all GitHub-hosted runners. | |
| Larger runners | Per runner concurrency limit | Varies by runner type | Established when setting up a runner. Normally 1,000 max for Linux CPU runners, but varies by type. See Job concurrency limits for GitHub-hosted runners. | Support ticket |
| Larger runners | Static IP limits | 10 IPs | 10 IPs per enterprise and organization. | Support ticket |
| Larger runners | Private IP scaling for vnet injection | 30% buffer | You need a buffer to accommodate the maximum job concurrency you anticipate. See Private IP scaling for vnet injection on larger runners. | Configurable Azure virtual network |
| Dependency caching | Uploads per minute | 200 per minute | Each repository is limited to 200 cache entry uploads per minute. If this limit is exceeded, subsequent cache upload attempts will fail until the rate limit resets. | |
| Dependency caching | Downloads per minute | 1500 per minute | Each repository is limited to 1500 cache entry downloads per minute. If this limit is exceeded, subsequent cache download attempts will fail until the rate limit resets. | |
| Dependency caching | Deletes per minute | 400 per minute | Each repository is limited to 400 cache delete operations per minute. If this limit is exceeded, subsequent cache delete attempts will fail until the rate limit resets. Each request to delete caches either by key or by ID counts towards this limit. |
GitHub Support can increase job concurrency limits for GitHub Actions. To request an increase, submit a support ticket.
| Runner type | GitHub plan | Total concurrent jobs | Maximum concurrent macOS jobs | Maximum concurrent GPU jobs |
|---|---|---|---|---|
| Standard GitHub-hosted runner | Free | 20 | 5 | Not applicable |
| Standard GitHub-hosted runner | Pro | 40 | 5 | Not applicable |
| Standard GitHub-hosted runner | Team | 60 | 5 | Not applicable |
| Standard GitHub-hosted runner | Enterprise | 500 | 50 | Not applicable |
| Larger runner | Team | 1000 | 5 | 100 |
| Larger runner | Enterprise | 1000 | 50 | 100 |
Note
The maximum concurrent macOS jobs is shared across standard GitHub-hosted runners and GitHub-hosted larger runners.
GitHub Support cannot increase storage limits for GitHub Actions.
| Plan | Artifact storage | Minutes (per month) | Cache storage |
|---|---|---|---|
| GitHub Free | 500 MB | 2,000 | 10 GB |
| GitHub Pro | 1 GB | 3,000 | 10 GB |
| GitHub Free for organizations | 500 MB | 2,000 | 10 GB |
| GitHub Team | 2 GB | 3,000 | 10 GB |
| GitHub Enterprise Cloud | 50 GB | 50,000 | 10 GB |
For information about cache storage limits and how to increase them, see Usage limits and eviction policy.
When using larger runners with vnet injection, you need to determine the appropriate subnet IP address range, for which we recommend adding a buffer to the maximum job concurrency you anticipate. For instance, if the network configuration's runners are set to a maximum job concurrency of 300, utilize a subnet IP address range that can accommodate at least 390 runners. Note that Azure reserves 5 IPs in every subnet (first 4 and last 1), which sets a minimum practical subnet size depending on runner requirements. Very small subnets (like /29 or smaller) may not provide enough usable addresses for your needs.
GitHub's REST API rate limits apply to GitHub Actions users, those that are commonly hit are:
Unauthenticated users - You can make unauthenticated requests if you are only fetching public data. Unauthenticated requests are associated with the originating IP address, not with the user or application that made the request.
The primary rate limit for unauthenticated requests is 60 requests per hour.
Authenticated users - You can use a personal access token to make API requests. Additionally, you can authorize a GitHub App or OAuth app, which can then make API requests on your behalf.
All of these requests count towards your personal rate limit of 5,000 requests per hour. Requests made on your behalf by a GitHub App that is owned by a GitHub Enterprise Cloud organization have a higher rate limit of 15,000 requests per hour. Similarly, requests made on your behalf by a OAuth app that is owned or approved by a GitHub Enterprise Cloud organization have a higher rate limit of 15,000 requests per hour if you are a member of the GitHub Enterprise Cloud organization. However, requests made by a higher-limit app reduce the remaining budget available for lower-limit authentication methods. For example, if an app with a 15,000 request limit makes 10,000 requests on your behalf, you will have exhausted the 5,000 request budget for your personal access tokens, even though the app has 5,000 requests remaining.
GitHub app installations - GitHub Apps authenticating with an installation access token use the installation's minimum rate limit of 5,000 requests per hour. If the installation is on a GitHub Enterprise Cloud organization, the installation has a rate limit of 15,000 requests per hour.
For installations that are not on a GitHub Enterprise Cloud organization, the rate limit for the installation will scale with the number of users and repositories. Installations that have more than 20 repositories receive another 50 requests per hour for each repository. Installations that are on an organization that have more than 20 users receive another 50 requests per hour for each user. The rate limit cannot increase beyond 12,500 requests per hour.
Primary rate limits for GitHub App user access tokens (as opposed to installation access tokens) are dictated by the primary rate limits for the authenticated user. This rate limit is combined with any requests that another GitHub App or OAuth app makes on that user's behalf and any requests that the user makes with a personal access token. For more information, see Rate limits for the REST API.
OAuth apps - For these requests, the rate limit is 5,000 requests per hour per OAuth app. If the app is owned by a GitHub Enterprise Cloud organization, the rate limit is 15,000 requests per hour.
GITHUB TOKEN - The rate limit for GITHUB_TOKEN is 1,000 requests per hour per repository. For requests to resources that belong to a GitHub Enterprise Cloud account, the limit is 15,000 requests per hour per repository.
Secondary rate limits - In addition to primary rate limits, GitHub enforces secondary rate limits in order to prevent abuse and keep the API available for all users, these are not configurable with GHEC. For more information, see Rate limits for the REST API.