Zusammenfassung

  • GitLab.com rechnet betroffene gehostete Jobs dem übergeordneten Namensraum des Projekts zu. Eigenständige Projekte und Untergruppen können deshalb dasselbe Kontingent beanspruchen.
  • Zusätzlich gekaufte Rechenminuten werden nach dem enthaltenen Monatskontingent verbraucht. Unverbrauchte Mengen bleiben für spätere Monate erhalten, sind aber nicht zwischen Gruppen übertragbar.
  • Ein ausreichendes Guthaben ersetzt weder einen passenden verfügbaren Runner noch die Berechtigung zur sicheren Ausführung. Auch selbst betriebene Runner beseitigen nicht die Verantwortung für Betrieb und Isolation.

Der Nutzen einer gemeinsamen Reserve

Ein gemeinsames Budget ist nicht von vornherein ein Risiko. Wenn ein Entwicklungsteam viel testet, während ein anderes gerade wenig Rechenzeit benötigt, kann eine gemeinsame Reserve den Bedarf auffangen. Die Organisation muss dann nicht für jedes Projekt einen eigenen ungenutzten Puffer vorhalten. Gerade schwankende Arbeitslasten liefern einen vernünftigen Grund für das Zusammenlegen.

Diese Begründung hat allerdings eine Voraussetzung: Jemand muss wissen, welche Schwankungen gemeinsam getragen werden. Bei GitLab.com ist die dafür maßgebliche Grenze nicht unbedingt das einzelne Projekt. Die Dokumentation zu Rechenminuten ordnet den Verbrauch dem Namensraum auf oberster Ebene zu, zu dem das ausführende Projekt gehört. Dass Teams eigene Projekte verwalten, verschafft ihnen also nicht automatisch ein eigenes Kontingent.

Man stelle sich zwei ausdrücklich hypothetische Projekte vor: eines für ein Kundenprodukt, eines für interne Werkzeuge. Sie liegen unter derselben obersten Gruppe, arbeiten aber an getrennten Aufgaben. Mehr betroffene Jobs des einen Projekts verringern den verbleibenden Spielraum für das andere. Dafür müssen weder gemeinsame Quelltexte noch ein gemeinsamer Veröffentlichungstermin existieren.

An der Außengrenze kehrt sich die Logik um. Nach den Regeln für zusätzliche Rechenminuten können gekaufte Minuten nicht zwischen Gruppen übertragen werden. Innerhalb der Gruppe wird geteilt; zwischen Gruppen bleibt die Reserve gebunden. Wer nur einen unternehmensweiten Gesamtbestand betrachtet, übersieht damit eine wesentliche Eigenschaft dessen, was gekauft wurde.

Verwaltungseinheit und Verbrauchseinheit

GitLab unterscheidet Benutzer- und Gruppennamensräume. Gruppen können Untergruppen enthalten, die bestimmte Einstellungen erben und andere selbst festlegen. Die Beschreibung der Namensräume erklärt diese Organisationsstruktur. Sie ist kein Beleg dafür, dass jede Untergruppe über eine eigenständige oberste Rechenreserve verfügt.

Auch die Identität der auslösenden Person darf nicht mit der Zuordnung verwechselt werden. Wer einen Job in einem fremden Projekt startet, verbraucht deshalb nicht automatisch das persönliche Kontingent. Entscheidend ist der Namensraum des Projekts, in dem der Job läuft. Die Erlaubnis, Arbeit auszulösen, und die Verantwortung für das belastete Budget können somit auseinanderfallen.

Das ist keine Aussage darüber, wie eine konkrete Firma ihre Teams organisiert. Eine Gruppe muss weder einer juristischen Gesellschaft noch einer Kostenstelle entsprechen. Die Produktregeln machen lediglich sichtbar, dass eine einmal gewählte Struktur mehrere Funktionen gleichzeitig erfüllen kann: Zusammenarbeit ordnen, Einstellungen vererben und den gemeinsamen Verbrauch begrenzen.

Beschaffung sollte diese Mehrfachfunktion kennen. Eine Projektleitung kann berechtigt sein, mehr Prüfungen anzustoßen, ohne über den nächsten Kauf zu entscheiden. Ein Budgetverantwortlicher kann den Kauf genehmigen, ohne die bevorstehende Testkampagne zu kennen. Dann fehlt nicht unbedingt Geld. Es fehlt möglicherweise die rechtzeitige Verbindung zwischen Bedarf und Entscheidungsbefugnis.

Zwei verschiedene Arten von Minuten

Die Laufzeit einer Pipeline und ihr Verbrauch an Rechenminuten beantworten unterschiedliche Fragen. Für den Verbrauch wird die Jobdauer in Sekunden durch sechzig geteilt und mit einem Kostenfaktor multipliziert. Zeiten im angelegten oder wartenden Zustand sind ausgenommen. Der Gesamtverbrauch summiert die ausgeführten Jobs, auch wenn sie gleichzeitig liefen.

Ein vereinfachtes Rechenbeispiel genügt: Drei parallele Jobs mit jeweils zehn Minuten Laufzeit und Kostenfaktor eins verbrauchen zusammen dreißig Rechenminuten. Ihr gemeinsames Ausführungsfenster kann zehn Minuten betragen. Weitere Jobs oder zusätzliche Zeiten sind in dieser Annahme nicht enthalten. Es handelt sich weder um einen Leistungsnachweis noch um eine Rechnung für einen Kunden.

Schnelleres Feedback kann den höheren Ressourceneinsatz rechtfertigen. Es kann aber auch durch das Beseitigen unnötiger Wiederholungen entstehen. Die Hinweise zur Pipeline-Effizienz behandeln unter anderem Abhängigkeiten, kritischen Pfad, Maschinenressourcen und die Vorbereitung der Ausführungsumgebung. Mehr Parallelität und weniger Arbeit sind verschiedene Eingriffe, selbst wenn beide die Wartezeit verkürzen können.

Für das gemeinsame Budget folgt daraus eine wichtige Einschränkung: Ein kürzerer Balken im Zeitdiagramm beweist keine geringere Belastung des Kontingents. Ebenso beweist ein geringerer Verbrauch nicht, dass die gleiche notwendige Prüfung effizienter erledigt wurde. Vielleicht wurde Doppelarbeit entfernt; vielleicht fehlt jetzt ein wichtiger Test. Die Einheit des Anbieters kann diese Wertung nicht übernehmen.

Was die Verbrauchsgrenze tatsächlich auslöst

GitLabs Regeln zur Kontingentdurchsetzung sehen Warnungen bei weniger als 25 Prozent, weniger als fünf Prozent und bei null verbleibendem Kontingent vor. Die Eigentümer des Namensraums erhalten E-Mails; zusätzlich erscheint ein Hinweis in der Anwendung. Diese Benachrichtigung zeigt den Stand an, nicht die Nachfrage, die andere Projekte gerade vorbereiten.

Ist das anwendbare Kontingent ausgeschöpft, bearbeiten Instanz-Runner keine neuen Jobs mehr. Wartende oder erneut versuchte Jobs, die solche Runner benötigen, werden auch innerhalb bereits begonnener Pipelines verworfen. Laufende Jobs dürfen zunächst weiterarbeiten, bis der Gesamtverbrauch des Namensraums das Kontingent um tausend Rechenminuten übersteigt. Jenseits dieser Grenze werden auch die dann noch laufenden Jobs verworfen.

Die tausend Minuten sind weder ein Puffer pro Projekt noch ein Versprechen, dass ein angefangener Ablauf fertig wird. Mehrere Jobs können gleichzeitig denselben aggregierten Spielraum beanspruchen. Es handelt sich auch nicht um ein zusätzliches monatliches Regelkontingent. Projekt- und Gruppen-Runner sind von dieser konkreten Verbrauchsgrenze nicht betroffen und verarbeiten weiter Jobs.

Ein solcher Stopp ist nicht gleichbedeutend mit einem Ausfall von GitLab. Der Dienst kann die dokumentierten Bedingungen korrekt anwenden, während ein Kunde nicht mehr die vorgesehenen Ausführungen erhält. Die passende Reaktion hängt deshalb von der Ursache ab: Ein Infrastrukturfehler benötigt Wiederherstellung, ein ausgeschöpftes Kontingent möglicherweise eine autorisierte Nachbestellung oder eine bewusste Arbeitsentscheidung.

Wer beides vermischt, adressiert leicht die falsche Stelle. Ein Betriebsteam kann eine Quote nicht durch die Reparatur eines gesunden Systems erweitern. Umgekehrt behebt eine Bestellung weder unpassende Runner-Einstellungen noch eine fehlende Ausführungsberechtigung. Die wirtschaftliche Grenze ist real, aber sie ist nicht die einzige Grenze im Ablauf.

Der Einkauf muss Ort und Alter festhalten

Zusätzliche Minuten werden erst nach dem enthaltenen Monatskontingent verbraucht. Nicht verbrauchte gekaufte Minuten können in spätere Monate mitgenommen werden. Ein Paket ist jedoch ein einmaliger Kauf, keine Menge, die jeden Monat neu bereitsteht. Bei einem Wechsel der Abonnementstufe bleiben gekaufte Minuten verfügbar, auch beim Wechsel zu Free.

Für die zeitliche Planung nennt GitLab eine Gültigkeit von zwölf Monaten ab Kauf. Der Ablauf wird derzeit nicht durchgesetzt; zugleich garantiert GitLab die Gültigkeit nach diesem Zeitpunkt nicht. Daraus folgt weder, dass sämtliche älteren Bestände bereits entfernt wurden, noch, dass ein noch sichtbarer Bestand dauerhaft zugesichert ist. Eine gegenwärtige Praxis ist keine unbefristete Vertragszusage.

Der räumliche Unterschied ist ebenso wichtig: Ein ungenutztes Paket in Gruppe A lässt sich nicht als gekauftes Paket nach Gruppe B übertragen. Dass ein Unternehmen dadurch zugleich Reserve und neuen Bedarf haben kann, ist eine aus der Regel abgeleitete Möglichkeit. Dieser Artikel hat keinen entsprechenden Schaden bei einem bestimmten Kunden festgestellt.

Einkaufsunterlagen sollten daher die empfangende Gruppe, das Kaufdatum und den noch nutzbaren Bestand unterscheiden. Kaufen kann der Gruppeneigentümer oder der Verwalter des Abrechnungskontos; dafür muss die passende Verknüpfung mit dem Gruppenabonnement bestehen. Derjenige, der eine dringende Lieferung verantwortet, verfügt nicht zwingend selbst über diese Rechte.

Die Antwort ist nicht automatisch eine Verlagerung von Projekten. Die untersuchten Quellen klären nicht sämtliche Folgen eines solchen Umzugs für Berechtigungen, Zusammenarbeit oder andere Abhängigkeiten. Belastbar ist die engere Schlussfolgerung: Bei künftigen Käufen sollte bewusst entschieden werden, in welcher Gruppe die gekaufte Berechtigung benötigt wird. Bereits vorhandene Pakete sind kein frei umbuchbares Unternehmensgeld.

Ein Guthaben ist noch keine Ausführungsumgebung

Runner führen die Jobs aus. Die Produktübersicht unterscheidet, wer sie betreibt und in welchem Geltungsbereich sie verfügbar sind. Für die Zuordnung eines Jobs zählen außerdem unter anderem Tags, Zustand, Kapazität und Fähigkeiten. Eine größere Reserve macht einen ungeeigneten Runner nicht geeignet.

GitLabs gehostete Runner nehmen dem Kunden konkrete Arbeit ab: Ein gewöhnlicher GitLab.com-Job erhält eine frische virtuelle Maschine, die danach entfernt wird. Besondere Angebote für Community-Beiträge unterscheiden sich davon. Die Dokumentation nennt außerdem das Ziel, 90 Prozent der Jobs innerhalb von 120 Sekunden zu starten. Das ist ein Serviceziel, keine in dieser Untersuchung gemessene Erfolgsquote und keine individuelle Reservierung.

Hinzu kommt die Vertrauensgrenze. Eine Merge-Anfrage aus einem Fork führt ihre Pipeline normalerweise im Fork und mit dessen Ressourcen aus. Ein berechtigtes Mitglied kann sie stattdessen im übergeordneten Projekt starten. Dabei trifft die Konfiguration des fremden Zweigs auf den Ausführungskontext und die Ressourcen des übergeordneten Projekts. Die Dokumentation zu Merge-Request-Pipelines fordert deshalb zur Prüfung nicht vertrauenswürdigen Codes auf. Geschützte Ressourcen haben eigene Beschränkungen; nicht jede solche Ausführung erhält Zugriff auf sämtliche Geheimnisse.

Auch ein selbst betriebener Runner ist mehr als eine Ausweichmöglichkeit bei knappem Guthaben. Die Sicherheitshinweise behandeln Hosts, Netzwerke, Ausführungsarten und die Trennung zwischen Jobs. Wiederverwendete, nicht flüchtige Umgebungen können projektübergreifende Risiken schaffen. Eine andere Verbrauchsregel hebt weder den Aufwand für Kapazität noch die Verantwortung für Isolation auf.

Die CI/CD-Analyse liefert wiederum Laufzeiten und Ergebnisse der Pipelines. Sie ergänzt den Verbrauchszähler, ersetzt ihn aber nicht. Ein tragfähiger Kauf verbindet beide Perspektiven: Welche Prüfung muss wann vorliegen, welche Gruppe darf die benötigten Minuten verbrauchen, und unter welchen Bedingungen kann der Job tatsächlich laufen? Erst diese Verbindung macht aus einem nominellen Bestand eine brauchbare Reserve.

Quellen und Reichweite

Grundlage sind die am 3. September 2026 geprüften GitLab-Dokumentationen zu Rechenminuten, Kontingentdurchsetzung, Zusatzkäufen, Namensräumen und Pipeline-Effizienz.

Die Ausführungsbedingungen sind durch die Seiten zu Runnern, gehosteten Runnern, Merge-Anfragen, Sicherheit und Analysen belegt. Kundenrechnungen, private Betriebsdaten und ausgehandelte Sonderverträge wurden nicht eingesehen. Die Kontingentaussagen betreffen GitLab.com und werden nicht pauschal auf Self-Managed oder Dedicated übertragen.