Fehler 500 und andere Serverfehler in Odoo eingrenzen

Ein Serverfehler hinterlässt drei Spuren: einen Statuscode im Browser, einen Zeitpunkt und eine Zeile im Serverprotokoll. Der Statuscode nennt, wie der Antwortende geantwortet hat; das Protokoll sagt, was schiefging. Die folgenden acht Schritte führen von der Meldung bis zur belegten Ursache und gelten für Odoo 20.0, die Version, die im September 2026 erschienen ist.

Was Sie vorab brauchen

• Eine Rolle mit Zugriff auf die Protokolle. In Odoo.sh sind Überwachung, Protokolle und Shell im Produktionszweig der Rolle Admin vorbehalten; die Rolle Developer (Entwickler) hat laut Dokumentation keinen Zugriff auf die Server-Logs. Auf einer eigenen Installation brauchen Sie den Zugang zum Dienst oder zur Protokolldatei.
• Die Angabe, wo Ihre Datenbank läuft. Für Odoo Online beschreibt die Dokumentation keinen Kundenweg zu einem Serverprotokoll; dort führen Reproduktion und Support-Ticket weiter (Schritte 6 und 8).
• Den genauen Aufruf: Adresse, ausgelöste Aktion, betroffene Datenbank, Version.
• Den Zeitpunkt in UTC und die Information, was unmittelbar vorher geändert wurde.
• Eine Kopie der Datenbank für den Test sowie einen Weg zurück (Testumgebung für Odoo, Backup-Strategie für Odoo).

Schritt für Schritt: vom Symptom zur Ursache

Schritt 1: Statuscode und Umfang festhalten

Der Statuscode grenzt die Rolle des Antwortenden ein, nicht den Namen des Programms. Ein 500 (Internal Server Error) bedeutet nach RFC 9110 Abschnitt 15.6.1, dass der antwortende Server auf eine unerwartete Bedingung gestoßen ist und die Anfrage deshalb nicht erfüllen konnte; welches Programm geantwortet hat, sagt der Code nicht, und die Erklärung liefert in der Regel das Protokoll der Anwendung. Ein 502 (Bad Gateway, Abschnitt 15.6.3) bedeutet, dass der antwortende Server in der Rolle eines Gateways oder Proxys eine ungültige Antwort von einem dahinterliegenden Server erhalten hat; ein 504 (Gateway Timeout, Abschnitt 15.6.5), dass er keine rechtzeitige Antwort erhalten hat. Bei 502 und 504 prüfen Sie zuerst den Dienst hinter dem Gateway und dessen Zeitgrenzen. Notieren Sie außerdem, ob eine Person, eine Aktion oder die ganze Datenbank betroffen ist. Ergebnis: Sie wissen, ob Sie im Protokoll der Odoo-Anwendung oder bei der vorgelagerten Komponente suchen.

Schritt 2: Den Zeitpunkt in UTC festhalten

Technische Protokolle stehen in UTC; die Dokumentation verlangt diese Zeitzone auch für Angaben im Support-Ticket, damit Kurve und Zeile zusammenpassen. Rechnen Sie die Uhrzeit aus dem Browser in UTC um und notieren Sie dazu die letzte Änderung davor: neuer Build, Modulinstallation, Import oder eine Anpassung im Studio. Ergebnis: ein Zeitfenster von wenigen Minuten und ein Verdacht, den Sie im Protokoll prüfen können.

Schritt 3: Das Protokoll öffnen

Auf Odoo.sh wählen Sie den betroffenen Zweig und den Reiter Logs (Protokolle). Er zeigt unter anderem odoo.log (laufender Server), update.log (Datenbankaktualisierungen), install.log (Installation), pg_slow_queries.log (auffällig lange Abfragen) und neutralize.log (Neutralisierung, nur Staging). Neue Zeilen erscheinen laufend, die Ansicht endet nach fünf Minuten und lässt sich neu starten; in der Shell liegt dieselbe Datei unter ~/logs/odoo.log. Einen Überblick über Ablage und Zugriff je Hostingmodell gibt Odoo überwachen.

Auf einer eigenen Installation schreibt Odoo standardmäßig die Stufen INFO, WARNING und ERROR auf die Standardfehlerausgabe; mit --logfile bestimmen Sie eine Datei, die ein Rotationsprogramm verwalten darf, weil Odoo sie nach dem Austausch neu öffnet. --log-db schreibt zusätzlich in das Modell ir.logging der genannten Datenbank; im Community-Zweig 20.0 erreichen Sie die Liste mit Entwicklermodus über Einstellungen ‣ Technisch ‣ Datenbankstruktur ‣ Protokollierung. Für Odoo Online überspringen Sie diesen Schritt und gehen zu Schritt 6.

Schritt 4: Die Zeilen lesen

Jede Zeile beginnt mit Datum und Uhrzeit, der Prozessnummer, der Stufe, der Datenbank und dem Namen des Protokollbereichs, gefolgt von der Meldung; die Dokumentation 20.0 zeigt ein solches Beispiel. Suchen Sie im Zeitfenster aus Schritt 2 zuerst die Zugriffszeile zur Anfrage. Im Community-Zweig 20.0 enthält sie die Anfragezeile mit Methode und Pfad, den Statuscode, die Länge der Antwort sowie Zahl und Dauer der Datenbankabfragen, geschrieben vom Protokollbereich odoo.http.server; mit --log-web erhalten Sie zusätzlich Anfrage- und Antwortzeilen mit Kopfzeilen.

Danach kommt der Traceback, die Aufzeichnung des Fehlerwegs: Die letzte Zeile nennt Ausnahmeart und Meldung, die Zeilen davor zeigen den Weg dorthin (Python-Dokumentation, Abschnitt Errors and Exceptions). Lesen Sie genau diese letzte Zeile.

Neben dem Traceback stehen Zeilen aus der Serververwaltung, die auf eine Auslastungsgrenze statt auf Anwendungscode deuten. Der öffentliche Community-Zweig 20.0 schreibt in odoo/service/server.py je Grenze eine eigene Zeile, und zwar nur im Mehrprozess-Betrieb einer eigenen Installation: „Virtual memory limit (…) reached.“, wenn ein Worker die weiche Speichergrenze limit_memory_soft überschreitet; der Worker beendet sich dann erst nach der laufenden Anfrage. „Max request (…) reached.“ nach der eingestellten Zahl an Anfragen (limit_request); auch hier endet der Worker erst nach der laufenden Anfrage. „CPU time limit (…) reached.“ beim Erreichen des CPU-Limits limit_time_cpu; der Worker wirft daraufhin eine Ausnahme im laufenden Aufruf, beendet sich aber nicht selbst. Für die harte Grenze limit_memory_hard setzt der Prozess eine Betriebssystemgrenze für den virtuellen Speicher; bei deren Überschreitung wird der Worker sofort beendet, ohne dass der Code dazu eine eigene Zeile schreibt. Der Hauptprozess meldet „(…) timeout after …s“, wenn ein Worker die Wanduhrgrenze limit_time_real überzieht, und beendet ihn; „Worker (…): dead“ steht für einen mit einem Fehlercode beendeten Worker. Für Odoo Online und Odoo.sh sagt die Dokumentation zu solchen Zeilen nichts; dort trägt die Plattform die Serververwaltung. Ergebnis: Sie können Ausnahme, Modulname, Prozessnummer und Zeitpunkt der betroffenen Anfrage nennen.

Schritt 5: Den Fehler einer Klasse zuordnen

Die folgende Zuordnung folgt aus den Schritten 1 bis 4; jeder Befund führt zu genau einem nächsten Schritt.

Befund im Protokoll	Bedeutung	Nächster Schritt
Traceback mit einer Ausnahme aus einem Modul, nur bei einer bestimmten Anfrage, wiederholbar	Fehler im Code, in einer Anpassung oder in den Daten	Schritt 6
Zeile „Virtual memory limit (…)“ oder „Max request (…)“ (eigene Installation, Mehrprozess-Betrieb, Quelle: Community-Zweig)	Der Worker hat die weiche Speicher- oder die Anfragegrenze erreicht und beendet sich erst nach der laufenden Anfrage; die Anfrage läuft noch zu Ende	Vorgang verkleinern oder aufteilen, Grenzen prüfen, bei Laufzeit Odoo ist langsam
Zeile „CPU time limit (…)“ oder „(…) timeout after …s“, oder ein mitten im Aufruf beendeter Worker ohne eigene Zeile (eigene Installation, Mehrprozess-Betrieb, Quelle: Community-Zweig)	Die Zeile „CPU time limit“ zeigt das CPU-Limit im laufenden Aufruf, die Zeile „timeout after“ die Wanduhrgrenze; für einen ohne eigene Zeile mitten im Aufruf beendeten Worker kommt die harte Speichergrenze in Betracht, ohne dass der fehlende Eintrag sie beweist	Vorgang verkleinern oder aufteilen, Grenzen prüfen, bei Laufzeit Odoo ist langsam
Fehlerzeitpunkt deckt sich mit Build, Modulinstallation oder Import	Verdacht: Die Änderung ist die Ursache; die zeitliche Deckung allein beweist es nicht	In einer Kopie gegenprüfen (Schritt 6), dann Schritt 7
Meldung nur in einer Testdatenbank	Testkopien (Duplikate und Back-up-Tests, bei Odoo.sh Staging- und Entwicklungsdatenbanken) sind neutralisiert	Prüfen, ob die Meldung aus einer abgeschalteten Funktion stammt

Schritt 6: Den Fehler in einer Kopie nachstellen

Führen Sie denselben Aufruf mit demselben Benutzer und denselben Rechten in einer Kopie aus. Auf Odoo Online duplizieren Sie die Datenbank im Datenbank-Manager; standardmäßig ist dabei die Option Zu Testzwecken aktiv, die alle externen Aktionen der Kopie abschaltet; Duplikate verfallen nach 15 Tagen. Auf Odoo.sh dient ein Staging-Zweig. Auf einer eigenen Installation legen Sie eine Kopie an und heben die Stufe nur so lange an, wie Sie sie brauchen: --log-level debug für alles oder --log-handler für einen Bereich, etwa odoo.sql_db:DEBUG; im Browser hilft der Entwicklermodus mit ?debug=1 (Entwicklermodus in Odoo). Ergebnis: Tritt der Fehler in der Kopie erneut auf, steckt die Ursache nicht allein in der Produktionsumgebung; lässt er sich nicht nachstellen, prüfen Sie Unterschiede bei Daten, Konfiguration und Umgebung, denn die Kopie ist neutralisiert und kann deshalb anders reagieren als die Produktion.

Schritt 7: Die Änderung zurücknehmen oder den Fehler beheben

Kam der Fehler mit einem Build, hält die Dokumentation fest, dass Odoo.sh bei einem fehlgeschlagenen Build im Produktionszweig den vorigen erfolgreichen Build zum Laden der Datenbank weiterverwendet; die Datenbank läuft dann mit der vorherigen erfolgreichen Revision weiter. Die fehlgeschlagene Aktualisierung lässt sich im Reiter Logs nachlesen, im update.log und im odoo.log. Ist eine Anpassung die Ursache, schalten Sie sie in der Kopie ab und prüfen erneut. Eine erhöhte Protokollstufe setzen Sie nach dem Test wieder zurück.

Schritt 8: Melden und nachhalten

In eine Meldung gehören Pfad, Uhrzeit in UTC, Datenbankname, Version, die Protokollzeilen und die Schritte zum Nachstellen. Bei Odoo Online und Odoo.sh führt der Weg über ein Support-Ticket; nur mit Zeitangabe kann der Support die Zeile zuordnen. Odoo 20.0 erschien im September 2026, der Standard-Support läuft laut Support-Übersicht bis September 2029 (geplant). Kopieren Sie die entscheidenden Zeilen aus der Datei, bevor eine Rotation sie entfernt.

So prüfen Sie das Ergebnis

• Lösen Sie dieselbe Aktion erneut aus; die Zeile mit derselben Ausnahmeart zum selben Pfad darf nicht wieder erscheinen, und die Zugriffszeile zeigt einen Statuscode unter 500.
• Vergleichen Sie dieselbe Uhrzeit am nächsten Tag: Wiederholt sich der Fehler zum selben Zeitpunkt, prüfen Sie als Nächstes eine geplante Aktion als Ursache; das Muster allein beweist es nicht.
• Kam der Fehler aus einer geplanten Aktion, warten Sie deren nächsten Lauf ab.
• Bewahren Sie die Zeilen aus dem Zeitfenster auf; nach einer Rotation fehlen sie.

Wenn etwas nicht klappt

Symptom	Ursache	Lösung
Zum gemeldeten Zeitpunkt steht keine Zeile	Protokoll in UTC, Browser in Ortszeit	Zeit umrechnen und einige Minuten davor und danach suchen, sonst über die Anfragezeile nach dem Pfad suchen
Nur der Statuscode, kein Traceback	Der Statuscode allein nennt keine Ursache und kein Programm. Bei 502 (Bad Gateway) und 504 (Gateway Timeout) beschreibt er nach RFC 9110 nur die Gateway-Rolle: der Antwortende hat vom dahinterliegenden Server eine ungültige beziehungsweise keine rechtzeitige Antwort erhalten. Ein Traceback der Odoo-Anwendung dahinter ist damit nicht ausgeschlossen und kann im Protokoll stehen	Bei 502 oder 504 sowohl die Gateway-Komponente und ihre Zeitgrenzen prüfen (das Beispiel der Dokumentation setzt 720 Sekunden je Richtung) als auch das Protokoll des dahinterliegenden Dienstes; bei 500 im Protokoll der Anwendung nachsehen und dort die Protokollstufe anheben
Eine Anfrage brach ab, ohne Ausnahme im Protokoll	Der fehlende Ausnahmeeintrag beweist keine bestimmte Ursache; möglich sind unter anderem die harte Speichergrenze (limit_memory_hard), die den Worker nach dem Community-Zweig ohne eigene Zeile mitten im Aufruf beendet, und die Wanduhrgrenze (limit_time_real), deren Überschreitung der Hauptprozess als “timeout after” meldet	Nach den tatsächlichen Befunden suchen: Zeile “timeout after”, Speicherverbrauch des Prozesses, eigene Grenzwerte; passt nichts, weitere Ursachen prüfen und den Vorgang verkleinern
Der Fehler erscheint nur in der Kopie	Die Kopie ist neutralisiert; einzelne Funktionen sind dort abgeschaltet	Prüfen, ob die Meldung aus einer abgeschalteten Funktion stammt; das rote Banner weist auf die Testumgebung hin
Der Fehler verschwand nach dem Neustart	Der Prozess wurde neu gestartet, die Ursache bleibt	Zeile vor dem Neustart sichern und dieselbe Ursache weiterverfolgen
Das Menü Protokollierung fehlt	Entwicklermodus aus oder Recht für das technische Menü fehlt	Entwicklermodus einschalten oder einen Administrator fragen
Kein Serverprotokoll auffindbar	Für Odoo Online ist in der Dokumentation kein Kundenweg zu einem Serverprotokoll beschrieben	Reproduzieren, Administrator-Aktivitätsprotokoll prüfen, Support-Ticket anlegen

Wann Sie Hilfe holen sollten

Ziehen Sie eine Entwickler- oder Partnerrolle hinzu, wenn die letzte Zeile des Tracebacks in ein eigenes Modul oder in eine Anpassung zeigt. Bei Fehlern, die auf beschädigte oder widersprüchliche Daten zurückgehen, ist die Wiederherstellung der sicherere Weg als eine Änderung in der Produktion (Odoo-Datenbank exportieren und wiederherstellen). Auf Odoo Online bleibt als Weg das Support-Ticket, weil Sie die Serverebene nicht selbst einsehen. Bleibt eine Anfrage langsam, ohne Fehlermeldung, gehört sie zur Ursachensuche bei langen Antwortzeiten (Odoo ist langsam).