Einen hängenden oder fehlgeschlagenen Lauf diagnostizieren

Diese Seite ist so geordnet, wie du hier ankommst: nach Symptom. Such die Zeile, die du wirklich siehst, lies, was sie bedeutet, und tu das eine, was genannt wird. Wo ein Thema seine eigene Seite hat, verweist diese darauf, statt sie zu wiederholen.

Vor der Diagnose: wo du hinschaust und wie du mehr siehst

Zwei Gewohnheiten machen jede Diagnose weiter unten schneller.

Wo du hinschaust – der Lauf, nicht die Aufgabe. Eine Aufgabe ist die Definition, ein Lauf ist eine Ausführung davon – und im Lauf liegen die Belege. Öffne die Aufgabe, wähle den Lauf und schalte auf die Linse Events: der vollständige, geordnete Ereignisstrom samt Fehlerereignis und dessen Meldung. Die Linse Baum zeigt die Gestalt (welcher Knoten scheiterte), Flame/Timeline zeigt, wohin die Zeit ging. Im Web-Terminal liefert task <id> Kosten, Dauer und letzte Aktivität, und logs <id> --follow streamt dieselben Ereignisse. Zur Trennung von Aufgabe und Lauf siehe Runs und Tasks.

Wie du mehr siehst – zwei unabhängige Regler. Wenn der Feed zu dünn ist, um überhaupt etwas zu diagnostizieren, hast du zwei orthogonale Regler:

Regler	Was er ändert	Wer ihn drehen darf
Ausführlichkeit (`density reduced\|chatty`)	Ob der Feed die Denkschritte des Agenten und die vollen Tool-Details zeigt. Voreinstellung reduziert.	Alle, pro Konto
Debug-Modus (`debug on\|off`)	Ob der Feed SupaClouds eigene Interna zeigt – MCP-Tool-Aufrufe, Scope-Auflösung, automatische Gate-Auflösungen, Gefahr-Eskalationen.	Nur wo ein Workspace-Admin die Obergrenze geöffnet hat

Siehe Die Live-Feed-Ausführlichkeit festlegen und Debug-Modus verwenden. Es sind verschiedene Achsen: Die Ausführlichkeit filtert Ereignisse, die der Feed ohnehin zeigen könnte; Debug enthüllt Ereignisse, die er sonst verbirgt.

Mein Agent tut gar nichts

„Pausiert — wartet auf deine Entscheidung“

Am Lauf steht das Banner „Pausiert — wartet auf deine Entscheidung“ – „Der Agent hat eine Frage gestellt oder braucht eine Freigabe, bevor er weitermacht. Sieh dir die Anfrage an, um fortzusetzen.“ Der Agent steht an einem Gate: ein gefährlicher Tool-Aufruf, eine offene Frage, eine visuelle Vorher-Nachher-Abnahme oder ein Modellklassen-Wechsel.

Entscheide es. Anfrage ansehen am Banner – oder von jeder Oberfläche aus: approvals / tool-approvals, dann approve-tool <id> / reject-tool <id> im Web-Terminal, /approvals in Telegram oder Discord, oder die Knöpfe Freigeben / Ablehnen direkt auf der zugestellten Karte.

Jedes Gate trägt eine Timeout-Richtlinie. Ein Deny-Gate wird nach einer Frist automatisch abgelehnt, und der Agent macht ohne die Aktion weiter. Ein Hold-Gate – Deployments, Migrationen, eine Gefahr-Eskalation mitten im Lauf, ein Modellklassen-Wechsel – blockiert unbegrenzt, bis ein Mensch entscheidet. Und bei einem Tool- oder Visual-Gate wird eine Zeile, die kein Urteil ist, zurückgehalten statt als Freigabe gewertet: Eine beiläufige Nachricht wiederholt nur den Hinweis zur Entscheidung, anstatt den Agenten zu entsperren. Alle Details in Agenten-Aktionen freigeben oder ablehnen.

Zwei ehrliche Grenzen. Ob die Entscheidung einer Gefahr-Eskalation den Lauf fortsetzen kann, hängt vom Agent-Harness ab: Nur Harnesses mit echter Pause (Claude, Gemini) machen nach der Freigabe weiter – bei den übrigen sagt die Gate-Karte das offen und nennt den tatsächlichen nächsten Schritt (Neustart oder Abbruch). Und ein Hold, dessen Task bereits beendet ist, wartet nicht mehr ewig: Er wird automatisch als abgelaufen geschlossen, weil kein Agent mehr da ist, den eine Freigabe wecken könnte.

„Pausiert — Nutzungsfenster voll“

Das Banner lautet „Pausiert — Nutzungsfenster voll“ – „Das vorausbezahlte Fenster des Anbieters ist ausgeschöpft. Dieser Lauf wird automatisch fortgesetzt, sobald sich das Fenster erneuert.“

Tu nichts. Das ist ein Abo-Anbieter (OAuth-Plan), dessen rollierendes Fenster voll ist; der Lauf nimmt seine Arbeit von selbst wieder auf, sobald sich das Fenster erneuert. Wenn du wissen willst, wie voll und wie bald: Berichte → Nutzung öffnen oder usage ausführen. Siehe Nutzung und Budget verfolgen.

„Agent pausiert — schreibe eine Nachricht um fortzufahren“

Im Aufgabendetail sitzt über dem Nachrichtenfeld ein Pause-Abzeichen: „Agent pausiert — schreibe eine Nachricht um fortzufahren“, mit dem Platzhalter „Agent ist pausiert — Anweisung eingeben und absenden…“. Hier wartet die Harness auf dich, nicht an einem Gate – nichts löst das nach einer Frist auf.

Tippe die Anweisung und sende sie (oder intervene <id> <msg> im Web-Terminal, /intervene aus dem Chat).

„Angehefteter Runner offline – wartet“

In der Runner-Zeile des Laufs steht „Angehefteter Runner offline – wartet“. Die Aufgabe ist an genau einen Runner angeheftet, und der ist gerade nicht erreichbar – der Dispatch wartet auf ihn, statt die Arbeit still woanders hinzuschicken.

Hol den Runner zurück (runners listet die Flotte mit Status) oder entferne die Anheftung, damit die Arbeit an jeden passenden Runner gehen darf. Was ein Runner ist und wie er sich verbindet, steht in Die Runner-Flotte.

Niemand nimmt die Arbeit auf

„Für diesen Workspace sind noch keine Runner verfügbar“

Die Einstellungen zeigen „Für diesen Workspace sind noch keine Runner verfügbar. Ein Organisations-Admin kann einen registrieren oder einen bestehenden Runner für diesen Workspace freigeben.“

Das ist ein Freigabe-Problem, kein Ausfall. Ein edge-Runner ist standardmäßig nicht vertrauenswürdig: Solange ihm kein Workspace freigegeben ist, bekommt er nichts zugewiesen – auch dann nicht, wenn er online und untätig ist. Die Meldung benennt die Lösung: Ein Organisations-Admin registriert einen Runner oder gibt einen bestehenden für diesen Workspace frei.

„Kein aktueller Heartbeat - der Runner ist möglicherweise nicht erreichbar.“

Die Runner-Übersicht markiert eine Zeile als Veraltet mit genau diesem Hinweistext (und Nie in der Spalte Letzter Heartbeat, wenn er sich nie gemeldet hat).

Entweder ist der Runner-Prozess aus, oder seine ausgehende Verbindung zum Hub ist blockiert. Er verbindet sich nur ausgehend über HTTPS – prüfe also den Runner-Host und dessen Egress, nicht deine eingehende Firewall. Ein veralteter Runner wird beim Dispatch übersprungen, und seine Arbeit wird neu eingereiht.

Ein Circuit Breaker eines Anbieters ist ausgelöst

Unter Operations zeigt die Karte Circuit Breaker – „Provider- und Projekt-Breaker, die aktuell ausgelöst (offen) sind oder sich erholen“ – einen Breaker als Offen, statt „Alle Breaker funktionsfähig.“ zu melden.

Ein Breaker löst nach drei aufeinanderfolgenden Fehlern derselben Art gegen denselben Anbieter oder dasselbe Projekt aus. Solange er Offen ist, scheitern Anfragen schnell oder weichen aus, statt weiter auf etwas einzuhämmern, das schon tot ist. Er erholt sich selbst: Nach 60 Sekunden Abkühlung geht er auf Halb offen, und der erste erfolgreiche Aufruf schließt ihn. Ein weiterhin toter Anbieter öffnet den Breaker beim nächsten Fehler einfach wieder.

Einen Breaker setzt man nicht zurück. Behebe den zugrunde liegenden Ausfall – oder warte ihn ab. Der Zustand ist dauerhaft: Ein ausgelöster Anbieter bleibt über einen Serverneustart hinweg ausgelöst, bis er wirklich wieder trägt.

Ich stoße an eine Grenze

„Plan-Limit erreicht“

Ein Toast erscheint: Plan-Limit erreicht – „Diese Aktion hat ein Limit deines aktuellen Tarifs erreicht. Upgrade für mehr Kapazität.“ – mit dem Link Tarif upgraden. Der Server hat die Anfrage mit 403 und dem Code quota_exceeded beantwortet und trägt das strukturierte Detail mit, das ein API-Client beispielsweise als Quota exceeded for 'apps.max_count' (5/5) samt Upgrade-URL sieht.

Das ist eine Berechtigungs-Obergrenze auf einer Anzahl (etwa der Zahl der Apps), keine Ausgaben- oder Nutzungswand. Hier wartet nichts und wiederholt sich nichts: Die Aktion ist nicht passiert. Schaffe entweder Kapazität unter diesem Schlüssel frei oder wechsle den Tarif.

Einem Modell geht mitten in der Aufgabe das Kontingent aus

Der Live-Feed meldet, dass das gepinnte Modell sein Kontingent erreicht hat und die Aufgabe auf einem anderen Modell derselben Klasse weiterläuft – oder es erscheint ein Freigabe-Gate mit der Frage, ob auf eine schwächere Klasse ausgewichen werden soll.

Wechsel innerhalb der Klasse sind automatisch; du musst nichts tun. Ein Klassenwechsel passiert nie automatisch, und sein Gate wartet unbegrenzt – die Aufgabe bleibt blockiert, statt still degradiert zu werden. Der ganze Mechanismus, die Klassenketten und die Grenzen gegen ein Weglaufen stehen in Wenn ein Modell sein Kontingent erreicht.

„Workspace monthly AI budget exhausted“

Der Start scheitert mit Workspace monthly AI budget exhausted ($120.00 spent or reserved). Increase the cap or disable hard stop. – oder mit dem anbieterbezogenen Gegenstück Provider 'anthropic' monthly AI budget exhausted. Increase the provider cap or disable hard stop. Die Karte KI-Budget zeigt dann den Status Gesperrt. Eine verwandte Meldung, Workspace monthly AI budget has no room for another in-flight task ($5.00 reserved per run). Increase the cap or disable hard stop., heißt: Die Grenze hat keinen Spielraum mehr, um für einen weiteren gleichzeitigen Lauf zu reservieren – selbst wenn sie noch nicht ausgegeben ist.

Drei Dinge lohnen sich hier zu wissen:

Das Budget gilt für API-Modus-Agenten (Bezahlung pro Token). Es begrenzt keinen Abo-Anbieter – der wird über seine Nutzungsfenster gemessen, also über den Fall „Pausiert — Nutzungsfenster voll“ weiter oben, nicht über diesen.
Hard Stop am Limit ist das, was aus einer Warnung eine Verweigerung macht. Ist er aus, läuft es mit einem Alarmstatus über die Grenze hinaus weiter; ist er an, werden neue Läufe gesperrt.
Mit eingeschaltetem Hard Stop kann auch ein laufender Lauf abgebrochen werden, sobald die Grenze überschritten wird; das Fehlerereignis des Laufs hält dann „Budget hard stop cancelled in-flight task“ fest.

Erhöhe die Monatsgrenze, erhöhe die Anbietergrenze oder schalte den Hard Stop aus – siehe Nutzung und Budget verfolgen.

Der Lauf ist fehlgeschlagen

„Git-Clone fehlgeschlagen — bitte Repo-URL, Branch und Zugangsdaten prüfen.“

Die Meldung lautet genau so. Arbeite sie in dieser Reihenfolge ab, denn die drei Fehler sehen von außen identisch aus: die Repo-URL (Tippfehler, falscher Host, privates Repo), der Branch (ein Standard-Branch, den es nicht mehr gibt), dann das Credential.

Ist die URL eine SSH-URL, bekommst du stattdessen eine schärfere Meldung: „Diese SSH-URL benötigt einen SSH-Key. Entweder ein SSH-Key-Credential zum Projekt hinzufügen oder die URL auf HTTPS umstellen und einen Access-Token nutzen.“

„Konnte keine Repositories abrufen“ oder eine Verwechslung von Token und SSH

Die Repo-Auswahl scheitert mit Konnte keine Repositories von {provider} abrufen (HTTP {status}). Bitte Credential und nötige Scopes prüfen. – oder mit „Der API-Request konnte nicht erstellt werden. Prüfe, ob ein Token-Credential statt eines SSH-Credentials ausgewählt ist.“

Ein Git-Credential hat eine Art, und die beiden Arten sind nicht austauschbar. Ein SSH Key authentifiziert den Git-Transport – klonen und pushen. Ein Access Token authentifiziert die API des Anbieters – Repositories auflisten, Issues lesen, Pull Requests öffnen, Repo-Sync. Also:

Auflisten, Issues, PRs, Sync → Access Token. Der Repo-Sync sagt es ausdrücklich: „Repo-Sync benötigt ein Access-Token-Credential. SSH-Credentials können nach dem Import zum Klonen und Pushen verwendet werden.“
Ist die Art richtig und es scheitert trotzdem, ist der HTTP-Status in der Meldung die Antwort: 401 heißt, der Token ist falsch oder abgelaufen, 403 heißt in der Regel, ihm fehlt ein Scope.

Ein Marketplace-Connector scheitert zur Laufzeit

Ein Connector-Lauf scheitert mit einem Fehler, der wie ein SupaCloud-Defekt klingt – ein nacktes 401, eine abgelehnte Anmeldung, ein Timeout –, während die Ursache im Fremdsystem liegt, mit dem der Connector spricht. Die Installation verdrahtet die SupaCloud-Seite (die Ressource, die Zugangsdaten, die Sandbox) und kann nicht ändern, was das andere System verlangt: ein WebDAV-Konto ohne lokales Passwort, eine Bank, die eine registrierte Produkt-ID will, ein Postfach mit Zwei-Faktor-Authentifizierung, das ein App-Passwort braucht.

Lege die Ressource unter Ressourcen an und weise nach, dass die Zugangsdaten dieses System wirklich erreichen, bevor du dem Connector die Schuld gibst. Die Voraussetzungen, die in der Praxis auftreten, stehen in Einen Marketplace-Connector installieren.

Ein Credential, eine Integration oder eine Einstellung verweigert sich

Ein Secret-Wert lässt sich nicht mehr anzeigen

Es gibt keinen Anzeige-Knopf, und das ist so gewollt: Ein gespeichertes Secret ist write-only. Die Oberfläche sagt es, wo sie kann – „Verschlüsselt gespeichert und nicht erneut angezeigt. Bei jeder Änderung erneut eingeben.“, „Write-only — wird nie wieder angezeigt”, „Secret-Werte werden nie angezeigt.“

Du holst einen Wert nicht aus SupaCloud zurück, du ersetzt ihn. Rotiere das Credential an der Quelle und trage den neuen Wert hier ein. Siehe Secrets in der Benutzeroberfläche verwalten.

Ein Workspace-Credential wird zugunsten des Organisations-Credentials ignoriert

Normalerweise gewinnt der spezifischste Scope – persönlich, dann Workspace, dann Organisation. Trägt ein Organisations-Credential das Kennzeichen Gesperrt, kehrt sich das um: „Gesperrt: Diese Organisations-Anmeldedaten haben Vorrang vor Workspace- und persönlichen Anmeldedaten gleichen Namens.“

Ein Workspace-Admin kann ein gesperrtes Organisations-Credential nicht übersteuern; nur ein Organisations-Owner oder -Admin kann es entsperren. Das ist Absicht – so wird ein abrechnungsrelevanter Schlüssel über alle Workspaces hinweg erzwungen. Die Vorrangtabelle steht in Secrets in der Benutzeroberfläche verwalten.

„Debug ist von einem Arbeitsbereich-Admin deaktiviert.“

Das Einschalten von Debug antwortet genau mit dieser Zeile.

Die Workspace-Obergrenze allow_debug ist standardmäßig aus, und die Prüfung ist fail-closed und wird serverseitig durchgesetzt – keine Oberfläche (Web-Terminal, Telegram, Discord) kann Interna sichtbar machen, solange sie zu ist. Ein Workspace-Admin öffnet die Obergrenze einmal; danach aktiviert jede Person Debug für ihre eigene Sitzung. Siehe Debug-Modus verwenden.

`/link` wird im Chat abgelehnt

Das Verknüpfen eines Chat-Kontos scheitert, und der Grund unterscheidet sich je Plattform:

Meldung	Bedeutung
„Aus Sicherheitsgruenden: Sende /link in einer Direktnachricht an den Bot — nicht in einem Server-Kanal, wo der Code fuer andere sichtbar waere.“	Discord nimmt `/link` nur in einer Direktnachricht an. In einem Server-Kanal wäre der Code öffentlich, also wird er dort abgelehnt.
„Dieses Discord-Konto ist bereits mit einem anderen SupaCloud-Benutzer verknuepft.“ / „Diese Telegram-ID ist bereits mit einem anderen Account verknüpft.”	Die Chat-Identität gehört jemand anderem. Dort zuerst die Verknüpfung lösen.
„Ungültiger oder abgelaufener Link-Token. Erzeuge einen frischen Token unter Einstellungen > Telegram.“	Der Einmal-Code war schon verbraucht oder ist abgelaufen. Erzeuge einen neuen.

„Mikrofon-Zugriff blockiert“

Die Spracheingabe meldet „Mikrofon-Zugriff blockiert. Klick auf das Schloss-Symbol links neben der URL, stelle Mikrofon auf Zulassen und lade die Seite neu.“ – und das ist bereits die vollständige Lösung, in dieser Reihenfolge. Zwei Nachbarn: „Kein Mikrofon gefunden. Bitte eines anschließen oder die Audio-Hochladen-Option nutzen.” und „Mikrofon ist gerade von einer anderen Anwendung belegt. Bitte schließe sie und versuche es erneut.“

Das ist eine Browser-Berechtigung, keine SupaCloud-Einstellung – kein Admin kann sie für dich erteilen. Siehe Spracheingabe nutzen.

Ich kann mich nicht anmelden

Meldung	Bedeutung	Was zu tun ist
„Single Sign-on ist für diese Organisation nicht verfügbar. Bitte auf anderem Weg anmelden.“	Für diese Organisation ist kein nutzbares OIDC-Single-Sign-on konfiguriert (oder die Berechtigung dafür ist nicht aktiv).	Melde dich mit Passwort oder einem verknüpften Social-Anbieter an; bitte einen Organisations-Admin, die SSO-Einrichtung abzuschließen.
„Dieser Bestätigungslink ist ungültig oder abgelaufen. Fordere in deinem Konto einen neuen an.“	Ein Bestätigungs- oder Magic-Link war schon benutzt oder ist verfallen. Solche Links sind absichtlich einmalig.	Fordere einen frischen an; schick nicht die alte Mail erneut.
„Du kannst deine einzige Anmeldemethode nicht entfernen. Füge zuerst ein Passwort oder einen anderen Anbieter hinzu.“	Du löst gerade das Letzte, womit du dich anmelden kannst – das würde dich aussperren. Wird bewusst verweigert.	Erst ein Passwort setzen oder einen zweiten Anbieter verknüpfen, dann lösen.
„Dein Konto wartet noch auf Freigabe durch einen Administrator.“	Das Konto existiert, ist auf dieser Instanz aber noch nicht freigegeben.	Warten – oder eine Instanz-Administratorin bzw. einen Instanz-Administrator fragen.

Die Anmeldung mit Google und GitHub – samt der Tatsache, dass eine Anbieter-E-Mail, die schon zu einem Konto gehört, nie automatisch zusammengeführt wird, und dass ein aktiviertes Zwei-Faktor-Verfahren auch beim Social-Login erzwungen wird – steht in Mit Google oder GitHub anmelden.

Trägt der Fehlerkörper den Code database_error, docker_error, vault_error oder internal_error, dann ist die Meldung, die du bekommen hast, alles, was ein Client je sieht: Diese vier fallen zu einem flachen „Database error“, „Docker error“, „Vault error“ bzw. „Internal error“ zusammen, bevor sie den Server verlassen. Das ist kein Fehler und keine Kürzung – es ist eine Schwärzung, damit ein SQL-Statement, ein Vault-Pfad oder eine interne Panic-Meldung niemals einen Browser erreicht. Jede andere Fehlerklasse behält ihren echten Text für Menschen – deshalb kann der Rest dieser Seite exakte Zeichenfolgen zitieren und diese vier nicht.

Hier gibt es für dich nichts weiter zu lesen, und ein erneuter Versuch hilft selten. Das Detail existiert nur im Serverprotokoll. Gib den Fall an eine Instanz-Administration weiter, mit drei Angaben: dem Zeitstempel, der Run-ID (oder der Task-ID und der Seite, auf der du warst) und welchen der vier Codes du gesehen hast. Damit findet sie den passenden Protokolleintrag, der die volle Ursache trägt.