GitHub Actions macOS Runner zu lange in der Warteschlange? Skalierungsentscheidung 2026

Ein iOS-Build steht auf „Queued“, bevor überhaupt ein Schritt läuft? Dann ist zunächst nicht der Build zu beschleunigen, sondern die Ursache der Warteschlange zu bestimmen.

Schnellste Entscheidung: Starten Sie nicht sofort wiederholt denselben Job und erweitern Sie nicht vorschnell. Prüfen Sie zuerst, ob ein Runner zugewiesen wurde, ob Workflow-Parallelität oder Labels die Zuweisung verhindern oder ob ein Problem bei GitHub-hosted macOS Runnern vorliegt. Erst wenn eigene macOS-Aufträge regelmäßig an der verfügbaren Ausführungskapazität scheitern, ist ein selbst gehosteter Mac Runner als zusätzliche Option zu prüfen. Er behebt keine Störung der GitHub-seitigen Planung.

Dieser Beitrag richtet sich an unabhängige Entwickler, deren iOS-Builds oder Veröffentlichungsjobs warten, sowie an kleine Teams, bei denen macOS-CI den Merge- oder Release-Ablauf bremst.
Auch Betreiber selbst gehosteter Runner finden hier Prüfungen für Online-Status, Labels und Auftragsannahme.

Zuletzt aktualisiert am 11.11.2026. Abgeglichen mit der Dokumentation zu GitHub Actions-Limits, der Beschreibung gehosteter Runner und der GitHub-Statusseite.

Warteschlange, Startfehler und Build-Fehler

Die angezeigte Gesamtdauer eines Workflows genügt nicht, um die Ursache zu finden. Ein Job kann lange vor der Zuweisung eines Runners warten. Er kann nach der Zuweisung beim Start scheitern. Oder er läuft bereits und wird erst bei einem Build- oder Testschritt langsam beziehungsweise fehlerhaft. Diese Fälle verlangen unterschiedliche Maßnahmen.

Öffnen Sie den betroffenen Workflow-Lauf und wählen Sie den konkreten Job aus. Prüfen Sie Status, Zeitachse und Protokoll: Gibt es bereits einen gestarteten Schritt? Wird ein Runner angezeigt? Ist der Job beendet, obwohl noch kein Schritt ausgeführt wurde? Dokumentation zur Fehlersuche empfiehlt, Workflow-Läufe und Jobprotokolle gezielt zu untersuchen, statt aus der Gesamtzeit auf die Fehlerstelle zu schließen (GitHub-Anleitung zur Workflow-Fehlersuche).

Für eine erste Sichtung kann die GitHub-CLI den Lauf samt Protokoll anzeigen:

gh run view RUN_ID
gh run view RUN_ID --log

Die folgenden Zeilen sind ein vereinfachtes Diagnosebeispiel, keine garantierte Ausgabe der CLI:

Job: ios-build
Status: Queued
Runner: noch nicht zugewiesen
Schritte: noch nicht gestartet

Sind keine Schritte angelaufen, untersuchen Sie Zuweisung, Runner-Verfügbarkeit und Workflow-Regeln. Gibt es dagegen bereits Protokollausgaben aus xcodebuild, Tests oder Skripten, liegt die Verzögerung nach dem Start. Dann helfen Build-Protokolle und Projektmessungen weiter; eine Änderung der Runner-Zahl behebt keinen Fehler im ausgeführten Schritt.

Was ist zu prüfen, wenn ein Job vor dem ersten Schritt abgebrochen wird?
Kontrollieren Sie zuerst, ob der Lauf durch eine Concurrency-Regel oder durch eine externe Beendigung abgebrochen wurde. Prüfen Sie anschließend die Zeitachse und die Meldung im Laufprotokoll. Ein Abbruch vor dem ersten Schritt ist kein Beleg dafür, dass der eigene Build fehlerhaft ist. Bei einer Concurrency-Regel kann ein neuerer Lauf einen ausstehenden Lauf derselben Gruppe ersetzen; die genaue Wirkung hängt von der Workflow-Konfiguration ab (Dokumentation zur Workflow-Concurrency).

GitHub Actions macOS Runner in der Warteschlange

Wenn ausschließlich macOS-Jobs warten, prüfen Sie zunächst den Status des gehosteten Runner-Dienstes und die Meldungen des konkreten Jobs. GitHub dokumentiert allgemeine Abläufe gehosteter Runner sowie Limits und Warteschlangenregeln. Außerdem kann ein macOS Runner laut offizieller Dokumentation verworfen werden, wenn er nicht rechtzeitig zur Verarbeitung gelangt (GitHub Actions-Limits). Das macht die Prüfung des Jobstatus wichtiger als bloßes wiederholtes Starten.

Gehen Sie in dieser Reihenfolge vor:

1. Öffnen Sie die GitHub-Statusseite und prüfen Sie, ob für Actions oder die betroffene Plattform eine aktuelle Beeinträchtigung gemeldet wird. Notieren Sie den Status zum Zeitpunkt der Diagnose. Eine grüne Statusanzeige allein beweist jedoch nicht, dass ein einzelner Job korrekt konfiguriert ist.
2. Suchen Sie im Job nach Hinweisen auf fehlende Runner, nicht verfügbare Kapazität oder einen Fehler bei der Zuweisung. Trennen Sie diese Meldungen von einem Fehler in einem bereits gestarteten Schritt.
3. Prüfen Sie, ob andere Plattform-Jobs desselben Workflows starten. Wenn nur der macOS-Job betroffen ist, ist das ein Hinweis für die weitere Untersuchung, aber kein Nachweis einer allgemeinen Plattformstörung.
4. Vergleichen Sie mehrere Läufe und Workflow-Ereignisse. Häufen sich Abbrüche vor dem ersten Schritt, sichern Sie Lauf-IDs, Zeitpunkte und relevante Meldungen, bevor Sie erneut ausführen.
5. Entscheiden Sie anhand der Statusseite und der Jobdetails, ob Abwarten oder ein erneuter Lauf sinnvoll ist. Wenn die Plattform keine Störung meldet, fahren Sie mit den Workflow- und Runner-Prüfungen fort.

Zwischen dem 03.11.2026 und dem 09.11.2026 meldeten Nutzer in einer GitHub-Community-Diskussion Probleme mit macOS-arm64-Jobs, darunter Kapazitätshinweise und Fehler vor dem Beginn von Schritten (Nutzerberichte in der Community-Diskussion). Das sind Einzelfallberichte. Sie bestätigen weder eine allgemeine Störung noch deren Ursache oder eine offizielle Fehlerbehebung. Verwenden Sie sie als Anlass, eigene Protokolle und den offiziellen Status zu prüfen, nicht als Diagnose.

Hinweis: Ein erneuter Lauf kann eine vorübergehende Situation umgehen, schafft aber keine zusätzliche Runner-Kapazität. Bei wiederholten Abbrüchen sollten Sie erst den Status und die Jobmeldungen sichern, statt identische Läufe ohne Diagnose zu erzeugen.

Selbst gehosteter Mac Runner und Auftragszuordnung

Ein selbst gehosteter Mac Runner kann nur Jobs übernehmen, die zu ihm passen und die er tatsächlich annehmen kann. Ein Gerät kann im Verwaltungsbereich sichtbar sein, aber dennoch keinen Auftrag erhalten, wenn es offline, ausgelastet oder nicht mit den im Workflow verlangten Labels beziehungsweise der Runner-Gruppe verknüpft ist. Umgekehrt kann ein Runner einen Job annehmen und danach beim Start der Runner-Anwendung oder eines Skripts scheitern. Das sind unterschiedliche Fehlerbilder.

Prüfen Sie den selbst gehosteten Runner in nachvollziehbarer Reihenfolge:

1. Kontrollieren Sie im Repository- oder Organisationsbereich, ob der Runner als online angezeigt wird. Prüfen Sie zusätzlich, ob er gerade einen Auftrag bearbeitet.
2. Vergleichen Sie die Labels des Runners mit den Labels, die im Workflow unter runs-on verlangt werden. Ein nicht passendes Label verhindert die Zuordnung, auch wenn die Maschine erreichbar ist.
3. Prüfen Sie, ob der Workflow Zugriff auf die Runner-Gruppe hat. Eine passende Maschine außerhalb der für den Workflow freigegebenen Gruppe ist nicht automatisch verfügbar.
4. Wenn der Runner als Dienst eingerichtet ist, prüfen Sie dessen Dienststatus und aktuelle Runner-Protokolle auf der Maschine. Ein Online-Eintrag ersetzt diese lokale Prüfung nicht.
5. Vergleichen Sie den Zeitpunkt der Auftragsannahme mit dem Start des Jobs. Wird der Auftrag nie zugewiesen, untersuchen Sie Verfügbarkeit und Routing. Wird er angenommen, aber die Ausführung beginnt nicht, untersuchen Sie Dienst, Maschine und Startprotokolle.

GitHub stellt eigene Hinweise zur Überwachung und Fehlerbehebung selbst gehosteter Runner bereit. Die Referenz zu selbst gehosteten Runnern beschreibt außerdem, wie Runner für Aufträge ausgewählt werden. Nutzen Sie diese Quellen, um Online-Status, Labels und Gruppenzugriff getrennt abzugleichen.

Kann ein selbst gehosteter Mac Runner die Warteschlange beim iOS-Build verkürzen?
Er kann eine zusätzliche Ausführungsoption für eigene macOS-Jobs sein, wenn die Runner-Zuordnung stimmt und die Maschine verfügbar ist. Das hilft nicht automatisch bei einem Fehler im Workflow, einer falsch gesetzten Gruppe oder einer GitHub-seitigen Planungsstörung. Ein zusätzlicher Runner sollte deshalb zunächst mit einem repräsentativen Build getestet werden.

Workflow-Concurrency und unnötige macOS-Aufträge

Wenn mehr Builds warten, sobald mehr Änderungen eingehen, prüfen Sie die Regeln Ihres Workflows, bevor Sie neue Hardware oder ein zusätzliches Ausführungsziel einplanen. Wiederholte Auslöser, mehrere gleichartige Workflow-Läufe, umfangreiche Matrix-Ausführungen und macOS-Schritte für Aufgaben, die keine Apple-Werkzeuge benötigen, können die eigene Nachfrage erhöhen. Das ist nicht dasselbe wie eine Einschränkung der GitHub-Plattform.

Suchen Sie in der Workflow-Datei nach concurrency, runs-on, strategy.matrix und den Ereignissen unter on. Prüfen Sie, ob Push, Pull Request und manuelle Ausführung dieselbe Prüfung parallel starten. Die Concurrency-Einstellungen steuern Läufe innerhalb der festgelegten Gruppe; abhängig von der Konfiguration kann ein ausstehender Lauf durch einen neueren ersetzt werden. Die Dokumentation erläutert die Regeln und Konfigurationsmöglichkeiten (Workflow-Concurrency in GitHub Actions).

Ein einfaches Beispiel für eine gruppierte Ausführung:

concurrency:
  group: ios-check-${{ github.ref }}
  cancel-in-progress: false

Diese Konfiguration ist kein allgemeines Rezept. Prüfen Sie, ob der Gruppenname zu Ihrer gewünschten Trennung nach Branch oder Ereignis passt. Insbesondere Release- und Signierläufe sollten nicht versehentlich mit gewöhnlichen Prüfungen in dieselbe Gruppe geraten. cancel-in-progress: false bedeutet außerdem nicht, dass jede ausstehende Ausführung unbegrenzt erhalten bleibt. Maßgeblich sind die dokumentierten Regeln für Concurrency und die tatsächlichen Laufmeldungen.

Woran lässt sich erkennen, dass die Workflow-Parallelität die Warteschlange verursacht?
Ein starkes Indiz ist, wenn betroffene Läufe dieselbe Concurrency-Gruppe verwenden oder regelmäßig durch neuere Läufe ersetzt werden, während die Plattform keine passende Störung meldet. Prüfen Sie die Ereignisse, Gruppenbezeichnungen und Abbruchmeldungen zusammen. Eine Änderung an den Workflow-Regeln kann unnötige eigene Konkurrenz verringern; sie garantiert nicht, dass gehostete Runner bei einer externen Kapazitätsbegrenzung sofort verfügbar werden.

Nicht jeder Auftrag muss auf macOS laufen. Statische Prüfungen, Teile von Tests oder vorbereitende Schritte können – sofern die Werkzeuge und Projektanforderungen es erlauben – vor den macOS-Build verschoben oder getrennt ausgeführt werden. Fassen Sie doppelte Prüfungen zusammen, wenn sie dieselben Eingaben und Ergebnisse abdecken. Ändern Sie dabei nicht die Release-Prüfung so, dass Signierung, Archivierung oder Tests unbemerkt entfallen.

Abnahme eines zusätzlichen Mac-Ausführungsziels

Bevor ein selbst gehosteter Mac Runner in den regulären CI-Ablauf aufgenommen wird, prüfen Sie ihn mit einem echten, repräsentativen Projektlauf. Eine erfolgreiche Verbindung allein belegt weder, dass die gewünschte Xcode-Version ausgewählt wird, noch dass der benötigte Build und die Tests funktionieren. Erfassen Sie daher Belege aus mehreren Stufen:

1. Der Workflow kann den Runner anhand der vorgesehenen Labels und Gruppe auswählen.
2. Der Job startet auf der erwarteten macOS-Umgebung und meldet die eingesetzte Werkzeugversion.
3. Das Projekt kann die vorgesehene iOS-Konfiguration bauen und die relevanten Tests ausführen.
4. Falls der Lauf signiert oder ein Archiv erzeugt, prüfen Sie die erwarteten Ergebnisse und den sicheren Umgang mit Zugangsdaten.
5. Dokumentieren Sie Lauf-ID, Runner-Zuordnung, Werkzeugauswahl, Fehlerprotokolle und Ergebnisartefakte. Entfernen Sie Geheimnisse aus Protokollen und sichern Sie Signiermaterial nur nach dem dafür vorgesehenen Verfahren.

Für eine solche Abnahme sind keine pauschalen Leistungswerte nötig. Entscheidend ist, ob der eigene Workflow verlässlich angenommen wird und die gewünschten Projektziele erfüllt. Eine lokale Messung mit denselben Eingaben lässt sich als Vergleichswert festhalten; sie ist aber kein Beleg für allgemeine Runner-Leistung.

Entscheidung nach Fehlerbild

Die folgende Gegenüberstellung trennt Maßnahmen, die ein Team selbst beeinflussen kann, von Fällen, in denen zunächst die GitHub-Seite zu prüfen ist.

Warten, anpassen oder zusätzliche Kapazität prüfen

Nutzen Sie die folgende Auswahl, bevor Sie einen Runner-Plan ändern. Bei einem Plattformhinweis ist Abwarten mit gesicherten Laufdaten meist angemessener als ein sofortiger Umbau. Bei einer fehlerhaften Label- oder Gruppenregel ist zuerst die Zuordnung zu korrigieren. Bei überflüssigen eigenen Aufträgen sollten Sie den Workflow bereinigen. Erst wenn ein wiederkehrender Bedarf übrig bleibt, lohnt die Prüfung eines zusätzlichen Mac-Ausführungsziels.

GitHub-hosted macOS Runner sind bequem, weil das Team die Runner-Maschine nicht selbst betreiben muss. Ihre Verfügbarkeit hängt jedoch von den dokumentierten Limits und der Dienstplanung ab. Selbst gehostete Runner geben dem Team mehr Einfluss auf die Ausführungsumgebung, bringen aber Pflege, Überwachung und sichere Verwaltung mit sich. Wer die Kosten einer gemieteten Umgebung einschätzen möchte, kann die Übersicht zu Mac-Mietpreisen als Ausgangspunkt heranziehen; konkrete Eignung für GitHub Actions muss anschließend im eigenen Workflow geprüft werden.

Damit bleibt die Entscheidung an überprüfbare Symptome gebunden: Erst feststellen, ob ein Job überhaupt gestartet wurde; dann Zuordnung, Concurrency und Plattformstatus auseinanderhalten; erst danach über zusätzliche Kapazität entscheiden. Wenn gehostete Runner, wiederholte Workflow-Auslöser und ein kleiner Pool eigener Macs jeweils eigene Nachteile zeigen, kann eine gemietete Mac-Umgebung von SFTPMAC eine weitere Option sein. Sie ist kein Mittel gegen GitHub-seitige Planungsfehler und sollte vor einer dauerhaften Nutzung mit dem eigenen iOS-Build, der Runner-Anbindung und den Sicherheitsanforderungen getestet werden. Einen Überblick über die Mac-Umgebung von SFTPMAC finden Sie dort.