FEHLERSUCHE

Erst Nachweise sammeln, dann die Bereitstellung ändern.

Genaue Dienstnamen, Ports, Log-Pfade, Runtime-Befehle und Reparaturverfahren sind release-spezifisch. Dieser Leitfaden liefert eine sichere Triage-Reihenfolge und ein Eskalationspaket; für Korrekturbefehle gilt die aktuelle offizielle Dokumentation.

Installation Offizielle Dokumentation ↗

Den Fehlerzustand sichern, bevor Sie reparieren.

Löschen Sie keine Daten, setzen Sie keine Zugangsdaten zurück, starten Sie keine Remote-Installer erneut und ändern Sie nicht mehrere Variablen zugleich — ohne Backup- und Rollback-Plan.

01 Umfang und Zeitpunkt erfassen: betroffene Benutzer, Projekte, Aufgaben, Hosts, Erstauftreten, letzter bekannter guter Zustand und letzte Änderungen.
02 Version und Topologie erfassen: MonkeyCode-Release/Commit, Bereitstellungsart, Betriebssystem, Host-Rollen, Ressourcen, Endpunkte und Konfigurationsänderungen ohne Geheimnisse.
03 Nachweise sichern: relevante Fehler, Zeitstempel, Request-IDs, Ressourcenmetriken, Festplattenzustand, Netzwerkergebnisse und bereinigte Logs.
04 Eine Grenze isolieren: Konsole, Umgebungshost, Git, Modell, Paketzugriff, DNS/TLS und Speicher getrennt testen.
05 Eine freigegebene Wiederherstellung nutzen: aktueller Dokumentation folgen, eine umkehrbare Änderung machen, Ergebnis prüfen und dokumentieren.

Den Vorfall der richtigen Grenze zuordnen.

Diese Prüfungen bestimmen eine Kategorie; sie sind keine undokumentierten Reparaturbefehle des Produkts.

Installer oder Konsole nicht verfügbar: aktuellen offiziellen Befehl, DNS/TLS, Host-Ressourcen, Speicherplatz, Installer-Quelle, Systemzeit und dokumentierte Voraussetzungen erneut prüfen.
Umgebung startet nicht: den getrennten Entwicklungshost prüfen — Kapazität, Speicher, Netzwerkrouten, kürzlich geänderte Images/Pakete und parallele Nachfrage.
Repository-Zugriff schlägt fehl: URL, Umfang der Zugangsdaten, Ablauf, Sperrung, Branch-Rechte, DNS/TLS und Anbieterverfügbarkeit prüfen.
Modellanfrage schlägt fehl: genaue Modell-ID, Endpunkt, Zugangsdaten, Quota, Region, Netzwerkroute, Timeout und Anbieterstatus prüfen.
Build oder Vorschau schlägt fehl: Befehle in der Umgebung reproduzieren; Abhängigkeiten, Ports, Festplatte, Arbeitsspeicher, Artefakte und Anwendungslogs prüfen.
Upgrade oder Wiederherstellung schlägt fehl: destruktive Änderungen stoppen, Zustand sichern, unterstützte Versionen vergleichen, Wiederherstellung getrennt testen und mit Nachweisen eskalieren.

Ein Issue reproduzierbar und sicher teilbar machen.

Veröffentlichen Sie niemals Tokens, Quellcode, interne URLs, Kundendaten, Prompts oder unredigierte Logs.

Zusammenfassung: erwartetes Ergebnis, tatsächliches Ergebnis, Auswirkung, Zeitstempel und Reproduzierbarkeit.
Umgebung: Version, Betriebsart, Betriebssystem, Host-Rollen und -Ressourcen sowie Netzwerkform.
Schritte: minimale nummerierte Reproduktion mit unkritischen Daten.
Nachweise: bereinigte Fehler, Logs, Screenshots, Metriken und Request-IDs.
Versuche: eine Änderung pro Versuch, Ergebnis und Rollback-Status.

Öffentliche Issue-Nachweise

Aktuelle Berichte zeigen, wo bessere Diagnosedaten zu holen sind.

Dies sind einzelne GitHub-Nutzerberichte — keine Häufigkeitsdaten, keine bestätigten Ursachen, keine Support-Zusagen und kein Beleg dafür, dass jede Bereitstellung betroffen ist. Der Issue-Status kann sich nach dem Prüfdatum ändern.

Modellanfrage: issue #870

Ein Nutzer meldete wiederholte Modellaufruf-Fehler und bat um klarere Hinweise zu Kontextlimits oder Ressourcen.

Bericht ansehen (offen) →

Umgebungsstart: issue #872

Ein Nutzer meldete langsame wiederholte Custom-Image-Pulls und gelegentliche Pull-Fehler.

Bericht ansehen (offen) →

Aufgabenwiederherstellung: issue #828

Ein Nutzer meldete eine Aufgaben-UI, die nach API-Fehlern im Status „executing" blieb, sowie wiederholte Fehler bei der Kontextkomprimierung.

Bericht ansehen (offen) →

Repository-Identität: issue #819

Ein Nutzer meldete einen 404 beim Verknüpfen einer GitHub-Website-Identität im internationalen gehosteten Dienst.

Bericht ansehen (offen) →

Vorschau: issue #842

Ein Nutzer meldete instabile PHP-Website-Vorschauen.

Bericht ansehen (offen) →

Übernehmen Sie keine destruktiven oder privilegierten Workarounds aus einem Issue, ohne betroffene Version, Backups, Zugriffsgenehmigung und aktuelle Maintainer-Hinweise zu prüfen. Erfassen Sie zuerst Ihre eigenen, bereinigten Nachweise.

ÖFFENTLICHE ISSUE-BERICHTE

Sicher eskalieren mit einem bereinigten, reproduzierbaren Bericht.

Issue #870 ↗Issue #872 ↗Issue #828 ↗Issue #819 ↗Issue #842 ↗

Kapazitäts-Check

Beide veröffentlichten Infrastruktur-Untergrenzen prüfen.

Das Erreichen dieser Untergrenzen belegt keine ausreichende Produktionskapazität.

Komponente	CPU	Arbeitsspeicher	Speicher
MonkeyCode-Konsole	2 cores	4 GB	40 GB
Entwicklungshost	8 cores	16 GB	100 GB

Vom MonkeyCode-Projekt veröffentlicht; geprüft am 05.08.2026. Reserven für Parallelität, Builds, Image-Caches, Repositorys, Logs und aufbewahrte Artefakte einplanen.

HÄUFIGE FRAGEN

Häufige Fragen, beantwortet

MonkeyCode lässt sich nicht installieren oder die Konsole ist nicht verfügbar — was prüfen?

Bestätigen Sie erneut den aktuellen offiziellen Installationsbefehl, DNS und TLS, Host-Ressourcen, Speicherplatz, die Installer-Quelle, die Systemzeit und dokumentierte Voraussetzungen. Ändern Sie jeweils nur eine umkehrbare Sache und folgen Sie für Korrekturbefehle der aktuellen Dokumentation.

Eine Entwicklungsumgebung startet nicht — wo schaue ich nach?

Prüfen Sie den getrennten Entwicklungshost: Kapazität, Speicher, Netzwerkrouten, kürzlich geänderte Images oder Pakete sowie parallele Nachfrage. Konsole und Umgebungshost sind unterschiedliche Rollen und fallen aus unterschiedlichen Gründen aus.

Modellanfragen schlagen fehl — wie diagnostiziere ich das?

Prüfen Sie die genaue Modell-ID, den Endpunkt, die Zugangsdaten, die Quota, die Region, die Netzwerkroute, den Timeout und den Anbieterstatus. Ein öffentliches Issue meldet Modellaufruf-Fehler ohne klaren Grund — sichern Sie daher Request-IDs und Anbieterantworten, bevor Sie die Konfiguration ändern.

Repository-Zugriff oder Git-Verknüpfung schlägt fehl — wodurch?

Prüfen Sie Repository-URL, Umfang der Zugangsdaten, Ablauf und Sperrung, Branch-Rechte, DNS/TLS und Anbieterverfügbarkeit. Ein öffentliches Issue meldet einen 404 beim Verknüpfen einer GitHub-Identität im internationalen gehosteten Dienst — validieren Sie Ihre konkrete Kombination aus Anbieter und Hosting.

Wie melde ich ein MonkeyCode-Problem sicher?

Liefern Sie einen bereinigten, reproduzierbaren Bericht: Zusammenfassung, Umgebung, minimale Schritte, Nachweise und versuchte Änderungen. Veröffentlichen Sie niemals Tokens, Quellcode, interne URLs, Kundendaten, Prompts oder unredigierte Logs.

EVIDENZHINWEIS

Issues zeigen Symptome, aber keine Häufigkeit und keine garantierte offizielle Lösung.

MONKEYCODE

Erst Nachweise sammeln, dann die Bereitstellung ändern.

MONKEYCODE DEUTSCH PRODUKTÜBERSICHT SELF-HOSTING SICHERHEIT & DATENSCHUTZ INSTALLATION MODELLGUIDE