„Can’t keep up“, Watchdog-Timeout und „Exception in server tick loop“ sind unterschiedliche Minecraft-Fehlerbilder. Prüfe zuerst, ob der Server weiterläuft, hart beendet wurde oder einen konkreten Programmfehler meldet. Lag kann außerdem vom Client oder Netzwerk kommen; Server-TPS erklären nicht jedes Ruckeln.
Die drei Meldungen auseinanderhalten
Minecraft berechnet die Spielwelt 20-mal pro Sekunde. Ein solcher Durchlauf heißt Tick. Für 20 TPS stehen im Mittel 50 Millisekunden pro Tick zur Verfügung. Dauerhaft höhere Tickzeiten verursachen Serververzögerungen; niedrige Client-FPS oder hohe Netzwerklatenz sind andere Ursachen und können auch bei stabilen 20 TPS auftreten.
| Logmeldung | Was tatsächlich passiert ist | Läuft der Server noch? |
|---|---|---|
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind |
Die Tickschleife hat einen zeitlichen Rückstand gemeldet; Ursache und aktueller Zustand müssen geprüft werden | Häufig ja; die Meldung allein beweist keine dauerhafte Überlast |
A single server tick took 60.00 seconds + Considering it to be crashed |
Ein einzelner Tick überschritt max-tick-time; der Watchdog hat den Prozess beendet |
Nein, hart beendet |
Exception in server tick loop |
Ein Fehler ist bis in die Hauptschleife durchgeschlagen | Nein, meist mit Crash-Report |
Dispatched async TPS command (Paper-Warnung) |
Unsere eigene TPS-Messung fragt den Server von außen ab | Ja — das ist normal |
Die letzte Zeile verwirrt regelmäßig: Paper meldet jede von außen kommende Abfrage als Warnung. Es ist unsere planmäßige Leistungsmessung alle rund fünf Minuten, kein Fehler und kein Eingriff in dein Spiel.
Der wichtigste Handgriff: bei Watchdog-Meldungen nach oben lesen
Der Watchdog-Kill ist ein Symptom, keine Ursache. Er sagt nur: irgendetwas hat den Server-Thread länger blockiert als erlaubt. Was ihn blockiert hat, steht woanders.
Es gibt zwei Fälle, und sie führen zu völlig verschiedenen Maßnahmen:
Fall 1 — der Watchdog kam zuerst. Vor der Watchdog-Zeile steht normaler Spielbetrieb. Dann ist die Tick-Zeit tatsächlich die Nachricht: etwas hat den Server im laufenden Betrieb eingefroren.
Fall 2 — der Watchdog kam hinterher. Vor der Watchdog-Zeile steht bereits Stopping server oder Preparing crash report. Dann war der Server schon vorher tot oder im Herunterfahren, und der Watchdog hat lediglich ein hängendes Beenden abgeräumt.
Dieser zweite Fall ist kein Randphänomen. In einem Supportfall vom 22. August 2026 stürzte der Server-Thread um 13:20:15 ab, begann ein sauberes Stopping server — und erst 60 Sekunden später feuerte der Watchdog. Wer dort die Tick-Dauer zur Ursache erklärt, schickt den Betreiber an der echten Fehlermeldung vorbei, die eine Minute weiter oben stand. Genau deshalb wertet unsere Konsolen-Analyse den Watchdog-Treffer bewusst als Letztes aus: Liegt im selben Logabschnitt eine spezifischere Signatur, bekommst du diese Aussage angezeigt und nicht „ein Tick war langsam“.
Schritt für Schritt zur Ursache
1. TPS-Verlauf im Panel prüfen
Öffne deinen Server im Panel. Unter „Performance (letzte 24h)“ siehst du den TPS-Verlauf; gemessen wird etwa alle fünf Minuten, solange der Server läuft. Die Form der Kurve sagt schon viel:
- Ein scharfer Einbruch zu einer bestimmten Uhrzeit → ein Ereignis. Gleiche die Uhrzeit mit dem Log ab: Weltgenerierung, ein Backup, ein Spieler in unerforschtem Gelände, ein Plugin-Task.
- Dauerhaft niedrige Werte → strukturelle Überlast. Hier hilft kein Neustart, sondern Entlastung.
- Sägezahnmuster → mögliche periodische Last. Prüfe GC-Pausen, Speicherauslastung und wiederkehrende Aufgaben zur selben Uhrzeit; das Muster allein beweist keinen Speicherdruck.
Bleiben die Werte über ein längeres Fenster niedrig, meldet sich das Panel von selbst mit dem Hinweis „TPS dauerhaft niedrig“.
2. MSPT messen — TPS allein reicht nicht
Nutze im Spiel /spark tps mit passenden Rechten oder in der Panel-Konsole spark tps ohne Schrägstrich. Prüfe beide Kennzahlen gemeinsam:
- TPS — Ticks pro Sekunde, Maximum 20.
- MSPT — Millisekunden pro Tick. Dauerhaft unter 50 ms bleibt Zeit für den nächsten geplanten Tick; prüfe zusätzlich Spitzen und die verbleibende Reserve.
Warum MSPT? Die Tickschleife wartet bei einer Verarbeitung unter 50 ms bis zum nächsten geplanten Tick, um 20 TPS einzuhalten. Deshalb können sowohl niedrige Tickzeiten als auch Zeiten knapp unter 50 ms als 20 TPS erscheinen. MSPT zeigt die verbrauchte Zeit und damit die verbleibende Reserve. Prüfe neben dem Mittelwert auch hohe Perzentile und einzelne Spitzen; bei 45 ms bleibt deutlich weniger Reserve als bei 15 ms, ohne dass daraus eine bestimmte nächste Lag-Ursache folgt.
Auf Paper ab 1.21 ist spark bereits enthalten, du musst nichts installieren.
3. Den Verursacher profilen
Rate nicht, welches Plugin schuld ist — miss es:
/spark profiler start --timeout 120
Spiele in diesen zwei Minuten die Situation nach, die laggt. Danach öffnest du den Ergebnis-Link, den der Server ausgibt. Der Report zeigt nach Zeitanteil sortiert, wohin die Tick-Zeit fließt: eine bestimmte Mod, ein Plugin-Task, Chunk-Laden, Entity-Verarbeitung oder die Garbage Collection.
Das ist der Punkt, an dem sich dieser Guide von „mehr RAM kaufen“ trennt. Der Profiler beantwortet die Frage, die eine Empfehlungstabelle nicht beantworten kann: Was genau kostet die Zeit auf deinem Server?
4. Gezielt entlasten
Was der Profiler zeigt, bestimmt die Maßnahme:
| Profiler zeigt | Wirksame Maßnahme |
|---|---|
| Chunk-Laden, Weltgenerierung | Sicht- und Simulationsweite anhand des Befunds begrenzen; bei Lag durch neue Gebiete eine zur Welt passende Vorabgenerierung prüfen |
| Entity-Verarbeitung | Mob-Farmen begrenzen, Tiere einzäunen statt frei laufen lassen, Item-Ansammlungen aufräumen |
| Redstone / Block-Ticks | Schnelle Dauerläufer und unnötige Redstone-Ticks reduzieren; nach jeder Änderung erneut messen |
| Ein einzelnes Plugin oder eine Mod | Testweise deaktivieren und erneut messen; Alternative oder aktuellere Version suchen |
| Garbage Collection | Heap-Auslastung, GC-Pausen und Allokationslast prüfen; mehr RAM nur bei bestätigtem Speicherengpass |
Der letzte Punkt ist wichtig: RAM behebt nur ein Speicherproblem. Wenn eine Redstone-Uhr die Tick-Zeit frisst, macht ein größerer Tarif den Server nicht schneller. Wie du euren Speicherbedarf anhand von Software, Welt und tatsächlicher Last planst, erklärt Minecraft RAM-Bedarf planen und messen.
5. max-tick-time — die Ausnahme, nicht die Lösung
Der Wert steht in server.properties und legt fest, ab welcher Tick-Dauer der Watchdog eingreift. Standard sind 60000 Millisekunden, also 60 Sekunden. Wird der Wert überschritten, beendet der Server sich selbst.
Viele Anleitungen im Netz empfehlen an dieser Stelle, den Watchdog mit -1 abzuschalten. Tu das nicht als Standardlösung. Der Watchdog erkennt einen zu lange blockierten Server-Thread. Mit -1 entfällt dieser Schutz; ein eingefrorener Prozess kann ohne den Watchdog-Abbruch weiter bestehen. Das garantiert weder Erreichbarkeit noch eine hilfreiche Fehlermeldung. Du hast die Anzeige entfernt, nicht das Problem.
Eine begründete Ausnahme kann sein: ein bekannter Vorgang dauert legitim lange. Der klassische Fall ist der erste Start eines großen Modpacks, bei dem Weltgenerierung und Mod-Initialisierung zusammen über eine Minute in einem Tick verbringen. Dann ist ein Wert von zum Beispiel 180000 (drei Minuten) vertretbar — vorübergehend, und mit dem Vorsatz, ihn nach dem ersten erfolgreichen Start zurückzusetzen.
Wenn Exception in server tick loop im Log steht
Diese Meldung verweist auf einen Programmfehler in der Tickschleife. Lies den vollständigen Stacktrace einschließlich vorhandener Caused by:-Zeilen. Genannte Mod-, Plugin- oder Bibliotheksklassen sind Hinweise auf den betroffenen Code; der Klassenname allein beweist noch keinen verantwortlichen Verursacher.
Vorgehen:
Caused by:suchen und den Klassennamen notieren.- Ordne genannte Mod-, Plugin- und Bibliotheksklassen ihren Versionen zu und prüfe Abhängigkeiten; leite die Ursache nicht nur aus einem Namen ab.
- Trat der Fehler nach einer Änderung auf (neue Mod, Update, neue Welt), diese Änderung zuerst rückgängig machen.
- Bleibt der Fehler unklar, den kompletten Abschnitt an den Support geben — mit Uhrzeit.
Die Konsolen-Analyse deines Servers erkennt diese Zeilen automatisch und erklärt jede erkannte Meldung im Klartext, inklusive Häufigkeit. Hast du nur ein Logstück von woanders, kannst du es in unseren Crash-Report-Analyzer einfügen — auch ohne Server bei uns.
Was wir automatisch für dich übernehmen
- Leistungsmessung ohne Zutun. TPS wird alle rund fünf Minuten erfasst und 24 Stunden lang im Panel dargestellt — du musst dafür kein Plugin installieren.
- Warnung bei anhaltender Schwäche. Bleibt die Leistung über ein belastbares Zeitfenster niedrig, wirst du darauf hingewiesen, statt es selbst bemerken zu müssen.
- Erklärte Logzeilen. Erkannte Meldungen bekommen Ursache und Lösung im Klartext, in deiner Sprache — und dort, wo ein passender Guide existiert, einen Link dorthin.
- Symptom-vor-Ursache-Regel. Steht im selben Logabschnitt eine aussagekräftigere Fehlermeldung als der Watchdog-Kill, zeigen wir dir diese.
Troubleshooting: Symptom, Prüfung, Lösung
| Symptom | Prüfung | Wahrscheinliche Lösung |
|---|---|---|
| Lag nur beim Erkunden neuer Gebiete | Tritt es auf, wenn Spieler in unerforschtes Gelände laufen? | Weltgenerierung; simulation-distance senken, Welt vorgenerieren lassen |
| Lag zu festen Uhrzeiten | Uhrzeit mit geplanten Aufgaben abgleichen | Backup oder Neustart-Plan zeitlich verschieben |
| Server stoppt ohne Fehler, Log endet abrupt | Steht A single server tick took am Ende? |
Watchdog-Kill; die Minute davor lesen |
| TPS zeigt 20, es ruckelt trotzdem | /spark tps — MSPT ansehen |
MSPT samt Spitzen prüfen; bei normaler Tickleistung auch Client-FPS und Netzwerk vergleichen |
| Nach dem Hinzufügen einer Mod | Mod entfernen und erneut messen | Mod-Konflikt oder lastintensive Mod |
| Sägezahn im TPS-Verlauf | Profiler auf Garbage Collection prüfen | Speicherdruck prüfen; RAM nur bei bestätigtem Engpass erhöhen |
| „Dispatched async TPS command“ im Log | Nur diese Zeile, sonst unauffällig | Nichts zu tun — unsere Messung |
FAQ
Ab welchem TPS-Wert merken Spieler etwas?
Das hängt vom Spielgeschehen, den Lastspitzen und den Spielern ab; es gibt keine verlässliche pauschale Wahrnehmungsgrenze. Minecraft strebt 20 TPS an. Prüfe zusätzlich MSPT und Spitzen, weil 20 TPS sowohl bei großer als auch bei kleiner verbleibender Tickreserve vorkommen.
Bringt mehr RAM gegen Lag?
Nur bei einem bestätigten Speicherengpass. Ein hoher Garbage-Collection-Anteil allein beweist keinen zu kleinen Heap: Prüfe Heap-Auslastung, GC-Pausen, Allokationslast und auffällige Erweiterungen gemeinsam. Zusätzlicher RAM behebt keine CPU-lastige Redstone-Uhr oder Mob-Farm. Miss zuerst und teste nach jeder Änderung dieselbe Last.
Soll ich den Watchdog abschalten?
Nein, nicht dauerhaft. -1 schaltet die automatische Watchdog-Erkennung eines blockierten Server-Threads ab. Eine befristete Erhöhung von max-tick-time für einen bekannten langsamen Vorgang wie den ersten Modpack-Start ist vertretbar — danach zurücksetzen.
Warum steht die Watchdog-Meldung nach „Stopping server“?
Weil der Server bereits beim Herunterfahren war und dabei hängen blieb. Der Watchdog hat dann ein hängendes Beenden abgeräumt, nicht einen laufenden Server erschlagen. Die Ursache steht vor dem Stopping server.
Hilft ein Neustart?
Gegen einen akuten Rückstand ja, gegen die Ursache nein. Kommt der Lag nach jedem Neustart innerhalb kurzer Zeit zurück, ist er strukturell — dann führt nur die Messung weiter.
Was ist der Unterschied zwischen view-distance und simulation-distance?
view-distance bestimmt, wie weit Spieler sehen; simulation-distance bestimmt, wie weit die Welt tatsächlich berechnet wird. Lies die aktuellen Werte in deinem konkreten Software- und Panel-Aufbau ab. Simulierte Chunks verursachen Tick-Arbeit; Sicht-Chunks müssen ebenfalls geladen, gegebenenfalls erzeugt und übertragen werden. Senke jeweils einen Wert kontrolliert und vergleiche Tickzeit, Speichernutzung und Spielverhalten unter derselben Last, statt aus dem Parameter allein eine feste Entlastung abzuleiten.
Wenn es weiterhin laggt
Sammle vor einer Supportanfrage drei Dinge: die genaue Uhrzeit des letzten Vorfalls, den Link deines spark-Profiler-Reports und die Angabe, welche Mods oder Plugins zuletzt dazugekommen sind. Damit lässt sich der passende Abschnitt im Log gezielt prüfen, statt eine allgemeine Optimierungsrunde zu drehen.
Allgemeine Stellschrauben über alle Spiele hinweg — Neustart-Pläne, Tarifwahl, Netzwerk — findest du im Guide Gameserver-Performance verbessern. Wie du Mods und Plugins sauber installierst und wieder entfernst, steht in Minecraft-Mods und Plugins installieren.
Du willst einen Server, auf dem TPS-Messung, Logerklärung und Warnungen ohne Zusatzarbeit dabei sind? Auf Minecraft-Server mieten findest du die passenden Tarife.
Quellen und Prüfstand
max-tick-time, Tickrate und Distanzen: PaperMC — server.properties. Dokumentiert den Standardwert von 60000 Millisekunden, das erzwungene Beenden bei Überschreitung, die Deaktivierung mit-1sowie die Standardwerte 10 fürview-distanceundsimulation-distance.- spark ist in Paper enthalten: PaperMC — Profiling. Ab Paper 1.21 ist kein separater Download nötig.
- TPS, MSPT und Tickreserve: spark — TPS and MSPT und The Tick Loop. Erklären den geplanten 20-TPS-Takt, die verbrauchte Tickzeit und warum Mittelwerte ohne Spitzenprüfung keine vollständige Lastdiagnose liefern.
- Profiler-Befehle: spark — Command Usage. Quelle für
/spark profiler start --timeout <sekunden>und/spark profiler stop.
Quellenabgleich: 7. Oktober 2026. Der beschriebene Supportfall ist ein historischer Fall vom 22. August 2026; für diese Überarbeitung wurde kein neuer Ingame-Lasttest durchgeführt. Standardwerte und Befehle können sich mit neuen Server-Versionen ändern; prüfe die verlinkte Herstellerdokumentation für deinen konkreten Aufbau.
Den Zeitpunkt statt nur den letzten Logsatz vergleichen
Notiere, wann Spieler Verzögerungen merken und wann die erste Warnung erscheint. Prüfe MSPT, TPS und den betroffenen Vorgang im selben Zeitraum: neue Chunks, ein Welt-Save oder ein Pluginereignis. Bei einem Watchdog-Abbruch liegt die verwertbare Ursache oft vor der Abschlussmeldung. Sichere Crashreport und letzten Logabschnitt, bevor ein Neustart sie unübersichtlich macht. Bleiben Serverticks normal und ist nur ein Spieler betroffen, prüfe dessen Ping und Client-FPS. Verändere max-tick-time erst nach der Ursache; eine längere Frist beschleunigt keinen Tick.
