Actions-Grenzwerte

Möglicherweise bist du durch GitHub Actions ratenbegrenzt, wenn du die Nutzung skalierst. Einige Grenzwerte können erhöht werden, indem du den Ihrer Websiteadministratoren kontaktierst.

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 Erhöhung unterstützen?
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.
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.
Ausführung des Workflows	Job-Matrix	256 Jobs / Workflow ausführen	Eine Job-Matrix kann maximal Jobs pro Workflow-Ausführung generieren. Das Limit gilt sowohl für von GitHub gehostete als auch selbstgehostete Runner.
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 auf GitHub gehosteten Runner	Auftragsparallelität	Varies	Weitere Informationen findest du unter Auftrags-Parallelitätsgrenzwerte für auf GitHub gehostete Runner.	Supportticket
Alle auf 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.
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 Weitere Informationen findest du unter Auftrags-Parallelitätsgrenzwerte für auf 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 virtuelles Azure-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.

Auftrags-Parallelitätsgrenzwerte für auf GitHub gehostete Runner

Der GitHub-Support kann die Parallelitätsgrenzwerte des Auftrags für GitHub Actions erhöhen. 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
Auf GitHub gehostete Standardrunner	Kostenlos	20	5	Nicht verfügbar
Auf GitHub gehostete Standardrunner	Pro	40	5	Nicht verfügbar
Auf GitHub gehostete Standardrunner	Team	60	5	Nicht verfügbar
Auf GitHub gehostete Standardrunner	Enterprise	500	50	Nicht verfügbar
Größerer Runner	Team	1000	5	100
Größerer Runner	Enterprise	1000	50	100

Hinweis

Die maximal gleichzeitigen macOS-Aufträge werden für auf GitHub gehostete Standardrunner und auf GitHub gehostete größere Runner freigegeben.

Speichergrenzwerte für alle auf GitHub gehostete Runner

Der GitHub-Support kann die Speichergrenzwerte 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

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. Beachte, dass Azure in jedem Subnetz 5 IPs reserviert (die ersten 4 und die letzte 1), was eine praktische Mindestgröße für das Subnetz festlegt, die von den Anforderungen der Runner abhängt. 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

Die REST-API-Limits von GitHub gelten für GitHub Actions Benutzende, die am häufigsten betroffen sind, sind:

        **Unauthentifizierte 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.

```
        **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.

        **Sekundäre Rate Limits**\- Zusätzlich zu den primären Rate Limits setzt GitHub sekundäre Rate Limits durch, um Missbrauch zu verhindern und die API für alle Benutzenden verfügbar zu halten; diese sind mit GHEC nicht konfigurierbar. Weitere Informationen finden Sie unter [AUTOTITLE](/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits).

Das Limit von Docker Hub für GitHub Actions

        **GitHub-gehostete Runner, die öffentliche Images ziehen:** Das Limit von Docker Hub wird nicht angewendet.

        **GitHub-gehostete Runner, die private Images pullen:** Das Pullen privater Images von Docker Hub unterliegt dem Limit der Rate.

        **Selbst gehostete Runner, die öffentliche oder private Images ziehen:** Das Ziehen von Images aus Docker Hub unterliegt immer dem Rate Limit.