Limits in GitHub Actions
You may be rate limited by GitHub Actions when you scale your usage. Some limits can be increased by contacting .
Unless otherwise stated, the expected behaviour when a limit is reached is that the workflow/job will get cancelled.
These limits are subject to change.
Existing system limits
| 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. | |
| 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 | Workflow run start | 50 workflow runs / minute | When the limit is reached, additional workflow runs will queue, causing delays in starting jobs. | Support ticket |
| Workflows execution | Job assignment | 100 jobs / minute / repo | When the limit is reached, additional jobs will queue, causing delays in starting jobs and updating the UI results of existing jobs. | Support ticket |
| Workflow execution | Job Matrix | 256 jobs / workflow run | A job matrix can generate a maximum of jobs per workflow run. This limit applies to both GitHub-hosted and self-hosted runners. | |
| 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. | |
| Hosted-runners | Job Concurrency | Varies | For more information about concurrency limits for standard and larger runners, see Limites d’utilisation, facturation et administration. | Support ticket |
| 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. | |
| Hosted-runners | Storage limits | Varies | For more information, see À propos de la facturation de GitHub Actions. | |
| Larger runners | Per runner concurrency limit | Varies by runner type | You establish when setting up a runner, normally 1,000 max for Linux CPU runners but varies by type. For more information, see Limites d’utilisation, facturation et administration. | Support ticket |
| Larger runners | Static IP limits | 10-50 IPs | 10 IPs for team plans, 50 IPs for enterprise, and the limit is configurable. | Support ticket |
| Larger runners | Private IP scaling for vnet injection | 30% buffer | 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. | - Configurable Azure virtual network |
Commonly hit dependent service limits
GitHub's REST API rate limits apply to GitHub Actions users, those that are commonly hit are:
-
Unauthenticated users - Vous pouvez présenter des requêtes non authentifiées si vous ne recherchez que des données publiques. Les requêtes non authentifiées sont associées à l'adresse IP d'origine, non pas à l'utilisateur ou à l'application à l'origine de la requêtes.
La limite de débit primaire pour les requêtes non authentifiées est de 60 requêtes par heure.
-
Authenticated users - Vous pouvez utiliser un personal access token pour présenter des requêtes d'API. En outre, vous pouvez autoriser une GitHub App ou une OAuth app, qui peut alors présenter des requêtes d'API en votre nom.
Toutes ces requêtes sont prises en compte dans votre limite personnelle de 5 000 requêtes par heure. Les requêtes présentées en votre nom par une GitHub App appartenant à une organisation GitHub Enterprise Cloud ont une limite de débit plus élevée de 15 000 requêtes par heure. De même, les requêtes présentées en votre nom par une OAuth app détenue ou approuvée par une organisation GitHub Enterprise Cloud ont une limite de débit plus élevée de 15 000 requêtes par heure si vous êtes membre de l'organisation GitHub Enterprise Cloud.
-
GitHub app installations - Les GitHub Apps qui s'authentifient avec un jeton d'accès d'installation utilisent la limite de débit minimale de l'installation, soit 5 000 requêtes par heure. Si l'installation est sur une organisation GitHub Enterprise Cloud, l'installation a une limite de débit de 15 000 requêtes par heure.
Pour les installations qui ne sont pas sur une organisation GitHub Enterprise Cloud, la limite de débit pour l'installation sera fonction du nombre d'utilisateurs et de référentiels. Les installations qui ont plus de 20 référentiels reçoivent 50 requêtes supplémentaires par heure pour chaque référentiel. Les installations d'une organisation comptant plus de 20 utilisateurs reçoivent 50 requêtes supplémentaires par heure et par utilisateur. La limite de débit ne peut pas dépasser 12 500 requêtes par heure.
Les limites de débit primaires pour les jetons d'accès utilisateur GitHub App (par opposition aux jetons d'accès à l'installation) sont dictées par les limites de débit primaires pour l'utilisateur authentifié. Cette limite de débit est combinée avec toutes les requêtes qu'une autre GitHub App ou OAuth app présente au nom de cet utilisateur et toutes les requêtes que l'utilisateur présente avec un personal access token. Pour plus d’informations, consultez « Limites de débit pour l'API REST ».
-
OAuth apps - Pour ces requêtes, le débit limite est de 5 000 requêtes par heure et par OAuth app. Si l'application appartient à une organisation GitHub Enterprise Cloud, le débit limite est de 15 000 requêtes par heure.
-
GITHUB TOKEN - La limite de débit pour
GITHUB_TOKENest de 1 000 requêtes par heure et par référentiel. -
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 Limites de débit pour l'API REST.