Actions-Grenzwerte

Sie könnten von GitHub Actions eingeschränkt werden, wenn Sie Ihre Nutzung skalieren. Einige Grenzwerte können durch Kontaktaufnahme mit uns über das GitHub-Support-Portal erhöht werden.

Sofern nicht anders angegeben, ist das erwartete Verhalten bei Erreichen eines Grenzwerts, dass der Workflow bzw. Auftrag abgebrochen wird.

Die Einschränkungen können sich jederzeit ändern.

Vorhandene System Limits

Limit Kategorie	Begrenzung	Schwellenwert	BESCHREIBUNG	Kann GitHub der Support erhöht werden?
Limit für die Ausführung von Workflows	Workflow-Ausführungszeit	35 Tage / Workflow ausführen	Wenn eine Workflow-Ausführung diesen Grenzwert erreicht, wird die Workflow-Ausführung abgebrochen. Dieser Zeitraum umfasst die Ausführungsdauer sowie die Warte- und Genehmigungszeit.
Limit für die Ausführung von Workflows	Genehmigungszeit des Gates	30 Tage	Ein Workflow kann bis zu 30 Tage auf die Genehmigungen der Umgebung warten.
Limit für die Ausführung von Workflows	Job-Matrix	256 Jobs / Workflow ausführen	Eine Auftragsmatrix kann maximal 256 Aufträge pro Workflowausführung generieren. Dieser Grenzwert gilt sowohl für GitHub-hosted als auch für selbst-gehostete Runner.
Limit für die Ausführung von Workflows	Erneut ausführen	50 Wiederholungen	Eine Workflowausführung kann maximal 50 Mal erneut ausgeführt werden. Dieser Grenzwert umfasst sowohl vollständige Wiederholungen als auch Wiederholungen einer Teilmenge von Aufträgen.

          <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Yes" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg> Supportticket |

| Workflows in der Warteschlange | Limit für Trigger-Ereignisse des Workflows | 1500 Ereignisse / 10 Sekunden / Repository | Jedes Repository ist auf Ereignisse, die einen Workflow ausführen, limitiert. | Supportticket | | Workflows in der Warteschlange | Ausführen von Workflows in der Warteschlange | 500 Workflow-Ausführungen / 10 Sekunden | Wenn das Limit erreicht ist, werden die Workflow-Ausführungen, die durch die Webhook-Ereignisse ausgeführt werden sollten, blockiert und nicht in die Warteschlange aufgenommen. Wiederverwendbare Workflows werden als eine einzige Entität betrachtet. Ein Ausführen von 30 wiederverwendbaren Workflows zählt in dieser Instanz zum Beispiel als 1. | | | Selbstgehostet | Runner-Registrierungen | 1500 Runner / 5 Minuten / Repository/Organisation/Unternehmen | Runner können pro Repository/Organisation/Unternehmen registriert werden. | Supportticket | | Selbstgehostet | Runner pro Runner-Gruppe | 10,000 Runner | Runner werden gleichzeitig pro Runner-Gruppe registriert. | | | Selbstgehostet | Auftragsausführungszeit | 5 Tage | Die einzelnen Aufträge in einem Workflow können bis zu 5 Tage lang ausgeführt werden. Wenn ein Auftrag dieses Limit erreicht, wird dieser beendet und schlägt fehl. | | | Selbstgehostet | Auftragswarteschlangenzeit | 24 Stunden | Ein Auftrag kann 24 Stunden lang in der Warteschlange sein, bevor er automatisch abgebrochen wird. | | | Alle GitHub-gehosteten Runner | Auftragsparallelität | Varies | Siehe Job-Parallelitätsgrenze für GitHub-gehostete Runner. | Supportticket | | Alle GitHub-gehosteten Runner | Auftragsausführungszeit | 6 Stunden | Jeder Job in einem Workflow kann bis zu 6 Stunden lang ausgeführt werden. Wenn ein Auftrag dieses Limit erreicht, wird dieser beendet und schlägt fehl. | | | | | Alle GitHubgehosteten Läufer | Speichergrenzwerte | Varies | Weitere Informationen finden Sie unter "Speicherbeschränkungen für alle GitHubgehosteten Läufer". | | | | | Größere Runner | Limit für Parallelität pro Runner | variiert nach Runnertyp | Wurde beim Einrichten eines Runners eingerichtet Normalerweise maximal 1.000 für Linux CPU-Runner, variiert jedoch je nach Typ Siehe Job-Konkurrenzgrenzen für GitHub-gehostete Runner. | Supportticket | | Größere Runner | Statische IP Limits | 10 IP-Adressen | 10 IPs pro Unternehmen und Organisation. | Supportticket | | Größere Runner | Private IP-Skalierung für VNet Injection | 30 % Puffer | Du benötigst einen Puffer, um die maximale Auftragsparallelität zu berücksichtigen, die du antizipierst. Weitere Informationen findest du unter Private IP-Skalierung für VNet-Einbindung auf größeren Runnern. | Konfigurierbares Azure virtuelles Netzwerk | | Zwischenspeichern von Abhängigkeiten | Uploads pro Minute | 200 pro Minute | Jedes Repository ist auf 200 Cacheeintragsuploads pro Minute beschränkt. Wenn dieser Grenzwert überschritten wird, schlagen nachfolgende Cacheuploadversuche fehl, bis die Ratenbeschränkung zurückgesetzt wird. | | | Zwischenspeichern von Abhängigkeiten | Downloads pro Minute | 1500 pro Minute | Jedes Repository ist auf 1500 Cacheeintragsdownloads pro Minute beschränkt. Wenn dieser Grenzwert überschritten wird, schlagen nachfolgende Cachedownloadversuche fehl, bis die Rate limit zurückgesetzt wird. | | | Zwischenspeichern von Abhängigkeiten | Löscht pro Minute | 400 pro Minute | Jedes Repository ist auf 400 Cachelöschvorgänge pro Minute beschränkt. Wenn dieser Grenzwert überschritten wird, schlagen nachfolgende Cachelöschversuche fehl, bis die Ratelimit zurückgesetzt wird. Jede Anforderung zum Löschen von Caches nach Schlüssel oder ID zählt zu diesem Grenzwert. | |

Parallelitätsgrenzwerte für von GitHub gehostete Runner

          GitHub Der Support **kann** die Parallelitätsgrenzen für Aufträge erhöhen GitHub Actions. Um eine Erhöhung anzufordern, übermittle ein Supportticket.

| Runnertyp | GitHub Plan | Total parallele Aufträge | Maximal parallele macOS-Aufträge | Maximale Anzahl gleichzeitiger GPU-Aufträge | |---|---|---|---|---| | Standard GitHub-gehosteter Runner | Kostenlos | 20 | 5 | Nicht verfügbar | | Standard GitHubgehosteter Läufer | Pro | 40 | 5 | Nicht verfügbar | | Standard GitHub-gehosteter Runner | Team | 60 | 5 | Nicht verfügbar | | Standard GitHub-gehosteter Runner | Enterprise | 500 | 50 | Nicht verfügbar | | Größerer Runner | Team | 1000 | 5 | 100 | | Größerer Runner | Enterprise | 1000 | 50 | 100 |

Speicherbeschränkungen für alle GitHub-gehosteten Runner

          GitHub Das Support-Team **kann** die Speicherlimits für GitHub Actions nicht erhöhen.

Plan	Artefaktspeicher	Minuten (pro Monat)	Cachespeicher
GitHub Free	500 MB	2,000	10 GB
GitHub Pro	1 GB	3,000	10 GB
GitHub Free für Organsationen	500 MB	2,000	10 GB
GitHub Team	2 GB	3,000	10 GB
GitHub Enterprise Cloud	50 GB	50,000	10 GB

Informationen zu Cachespeicherlimits und zur Erhöhung dieser Grenzwerte finden Sie unter Nutzungsbeschränkungen und -entfernungsrichtlinien.

Private IP-Skalierung für VNet-Einbindung auf größeren Runnern

Bei der Nutzung größerer Runner mit VNet-Einbindung musst du den geeigneten Subnetz-IP-Adressbereich ermitteln. Dafür wird empfohlen, einen Puffer zur erwarteten maximalen Auftragsparallelität hinzuzufügen. Wenn die Runner der Netzwerkkonfiguration beispielsweise auf eine maximale Parallelität von 300 Jobs festgelegt sind, verwende einen Subnetz-IP-Adressbereich, der mindestens 390 Runner aufnehmen kann. Beachten Sie, dass Azure 5 IPs in jedem Subnetz (erste 4 und letzte 1) reserviert, die je nach Läuferanforderungen eine minimale praktische Subnetzgröße festlegt. Sehr kleine Subnetze (z. B. /29 oder kleiner) stellen möglicherweise nicht genügend verwendbare Adressen für deine Anforderungen bereit.

Häufig erreichte Grenzwerte für abhängige Dienste

          GitHubDie [REST-API-Geschwindigkeitsbeschränkungen](/rest/using-the-rest-api/rate-limits-for-the-rest-api) gelten für GitHub Actions Benutzer, die häufig getroffen werden:

* Nicht authentifizierte Benutzer-Sie können nicht authentifizierte Anforderungen vornehmen, wenn Sie nur öffentliche Daten abrufen. Nicht authentifizierte Anforderungen sind der ursprünglichen IP-Adresse und nicht der Person oder Anwendung zugeordnet, die Anforderungen erstellt.

Für nicht authentifizierte Anforderungen ermöglicht die primäre Ratenbegrenzung bis zu 60 Anforderungen pro Stunde. * Authentifizierte Benutzer-Sie können eine personal access token verwenden, um API-Anforderungen zu stellen. Außerdem können Sie eine OAuth app oder GitHub App autorisieren, die API-Anforderungen in Ihrem Namen erstellen kann.

Alle diese Anforderungen zählen zu deiner persönlichen Ratenbegrenzung von 5.000 Anforderungen pro Stunde. Anforderungen, die in Ihrem Namen von einer GitHub App im Besitz einer GitHub App-Organisation gestellt werden, weisen eine höhere Ratenbegrenzung von 15.000 Anforderungen pro Stunde auf. Ebenso haben Anforderungen, die in Ihrem Auftrag von einem OAuth app durchgeführt werden, das im Besitz einer GitHub Enterprise Cloud Organisation ist oder von ihr genehmigt wurde, ein höheres Limit von 15.000 Anforderungen pro Stunde, wenn Sie Mitglied der GitHub Enterprise Cloud Organisation sind. Anforderungen von einer App mit höheren Grenzwerten verringern jedoch das verbleibende Budget, das für Authentifizierungsmethoden mit niedrigeren Grenzwerten verfügbar ist. Wenn eine App mit einem Anforderungslimit von 15.000 beispielsweise 10.000 Anforderungen in Ihrem Auftrag durchführt, haben Sie das Budget von 5.000 Anforderungen für Ihre personal access tokens ausgeschöpft, obwohl die App noch 5.000 Anforderungen übrig hat. * GitHub-App-Installationen-GitHub Apps, die sich mit einem Installationszugriffstoken authentifizieren, verwenden den minimalen Ratengrenzwert der Installation von 5.000 Anforderungen pro Stunde. Wenn sich die Installation in einer GitHub Enterprise Cloud-Organisation befindet, hat die Installation eine Ratenbegrenzung von 15.000 Anforderungen pro Stunde.

Bei Installationen, die sich nicht in einer GitHub Enterprise Cloud-Organisation befinden, wird die Ratenbegrenzung der Installation anhand der Anzahl von Benutzenden und Repositorys skaliert. Installationen mit mehr als 20 Repositorys erhalten weitere 50 Anforderungen pro Stunde für jedes Repository. Installationen in einer Organisation mit mehr als 20 Benutzern erhalten weitere 50 Anforderungen pro Stunde für jeden Benutzer. Die Ratenbegrenzung darf nicht mehr als 12.500 Anforderungen pro Stunde betragen.

Primäre Ratenbegrenzungen für GitHub App-Benutzerzugriffstoken (im Gegensatz zu Installationszugriffstoken) werden durch die primären Ratenbegrenzungen für den authentifizierten Benutzer bestimmt. Diese Ratenbegrenzung wird mit allen Anforderungen kombiniert, die andere GitHub App or OAuth app im Namen dieses Benutzers vornehmen, sowie alle Anforderungen, die der Benutzer mit einer personal access token durchführt. Weitere Informationen finden Sie unter Ratenbegrenzungen für die REST-API. * **OAuth-Apps -**Bei diesen Anforderungen beträgt die Ratenbegrenzung 5.000 Anforderungen pro Stunde pro OAuth app. Wenn sich die App in einer GitHub Enterprise Cloud-Organisation befindet, hat die Installation eine Ratenbegrenzung von 15.000 Anforderungen pro Stunde. * GITHUB-TOKEN-Die Ratenbegrenzung für GITHUB_TOKEN beträgt 1.000 Anforderungen pro Stunde pro Repository. Für Anforderungen an Ressourcen, die zu einem GitHub Enterprise Cloud-Konto gehören, beträgt die Ratenbegrenzung von 15.000 Anforderungen pro Stunde pro Repository. * Sekundäre Ratenlimits- Zusätzlich zu primären Ratenlimits werden sekundäre Ratenlimits erzwungen, GitHub um Missbrauch zu verhindern und die API für alle Benutzer verfügbar zu halten; diese sind nicht mit GHEC konfigurierbar. Weitere Informationen finden Sie unter Ratenbegrenzungen für die REST-API.

Docker Hubs Ratenbegrenzung für GitHub Actions

•         **
          GitHub-gehostete Runner, die öffentliche Images abrufen:** Die Begrenzung der Abrufrate von Docker Hub wird nicht angewendet.
  

•         **
          GitHub gehostete Läufer ziehen private Images:** Das Abrufen privater Bilder aus Docker Hub unterliegt dem Grenzwert für die Rate.
  

•         **Self-gehostete Läufer, die öffentliche oder private Images abrufen:** Das Abrufen von Images aus Docker Hub unterliegt immer den Ratenlimits.