Los tres mensajes de lag más frecuentes en el log de Minecraft no significan lo mismo: Can't keep up! Is the server overloaded? significa que tu servidor sigue funcionando, pero no da abasto. A single server tick took 60.00 seconds significa que el freno de emergencia integrado lo ha cerrado de forma forzada. Exception in server tick loop significa que un error concreto del programa ha roto el bucle de juego. Si tratas los tres igual, casi siempre arreglas lo equivocado.
Diferenciar los tres mensajes
Minecraft calcula el mundo del juego 20 veces por segundo. Cada pasada se llama tick y debe durar como máximo 50 milisegundos. Todo el lag que notas es una desviación respecto a ese único número.
| Mensaje de log | Qué ha pasado realmente | ¿El servidor sigue funcionando? |
|---|---|---|
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind |
Los ticks tardan más de 50 ms, el servidor está recuperando retraso | Sí, pero se nota pesado |
A single server tick took 60.00 seconds + Considering it to be crashed |
Un solo tick superó max-tick-time; el Watchdog cerró el proceso |
No, cerrado de forma forzada |
Exception in server tick loop |
Un error llegó hasta el bucle principal | No, normalmente con crash report |
Dispatched async TPS command (aviso de Paper) |
Nuestra propia medición de TPS consulta el servidor desde fuera | Sí, esto es normal |
La última línea suele confundir: Paper marca como aviso cada consulta que llega desde fuera. Es nuestra medición de rendimiento programada cada unos cinco minutos, no un error ni una intervención en tu partida.
El paso más importante: en avisos del Watchdog, leer hacia arriba
El cierre por Watchdog es un síntoma, no una causa. Solo dice esto: algo ha bloqueado el hilo del servidor durante más tiempo del permitido. Qué lo ha bloqueado aparece en otro lugar.
Hay dos casos, y llevan a medidas totalmente distintas:
Caso 1: el Watchdog apareció primero. Antes de la línea del Watchdog hay actividad normal del juego. Entonces el tiempo de tick sí es el mensaje: algo ha congelado el servidor mientras estaba funcionando.
Caso 2: el Watchdog apareció después. Antes de la línea del Watchdog ya aparece Stopping server o Preparing crash report. Entonces el servidor ya estaba muerto o apagándose, y el Watchdog solo limpió un cierre que se había quedado colgado.
Este segundo caso no es una rareza. En un caso de soporte del 22 de agosto de 2026, el hilo del servidor se cayó a las 13:20:15, empezó un Stopping server limpio, y solo 60 segundos después se disparó el Watchdog. Quien ahí declara que la causa fue la duración del tick envía al administrador lejos del mensaje de error real, que estaba un minuto más arriba. Precisamente por eso nuestro análisis de consola evalúa el impacto del Watchdog deliberadamente al final: si en la misma sección del log hay una firma más específica, verás esa explicación y no «un tick fue lento».
Paso a paso hasta la causa
1. Revisar el historial de TPS en el panel
Abre tu servidor en el panel. En «Rendimiento (últimas 24 h)» ves el historial de TPS; se mide aproximadamente cada cinco minutos mientras el servidor está en marcha. La forma de la curva ya dice mucho:
- Una caída brusca a una hora concreta → un evento. Compara la hora con el log: generación de mundo, una copia de seguridad, un jugador en terreno inexplorado, una tarea de plugin.
- Valores bajos de forma constante → sobrecarga estructural. Aquí no ayuda reiniciar, sino reducir carga.
- Patrón en dientes de sierra → típico de presión de memoria: el servidor trabaja, la Garbage Collection interrumpe, y se repite.
Si los valores se mantienen bajos durante una ventana larga, el panel te avisa por sí solo con el mensaje «TPS permanentemente bajos».
2. Medir MSPT: los TPS por sí solos no bastan
Escribe /spark tps en la consola. El comando devuelve dos números, y el segundo es el más importante:
- TPS: ticks por segundo, máximo 20.
- MSPT: milisegundos por tick. Todo hasta 50 ms está sano.
¿Por qué MSPT? Bukkit, Spigot y Paper frenan procesos del servidor para evitar una caída. Por eso la pantalla puede mostrar 20 TPS perfectos mientras el servidor ya está trabajando al límite. Un valor de MSPT de 45 ms significa: estás a una granja de mobs de empezar a tener lag visible, aunque el indicador de TPS todavía parezca perfecto.
En Paper desde la versión 1.21, spark ya viene incluido; no tienes que instalar nada.
3. Perfilar al causante
No adivines qué plugin tiene la culpa; mídelo:
/spark profiler start --timeout 120
Durante esos dos minutos, reproduce la situación que provoca lag. Después abre el enlace de resultados que muestra el servidor. El informe muestra, ordenado por porcentaje de tiempo, a dónde se va el tiempo de tick: una mod concreta, una tarea de plugin, carga de chunks, procesamiento de entidades o la Garbage Collection.
Este es el punto en el que esta guía se separa de «comprar más RAM». El profiler responde a la pregunta que una tabla de recomendaciones no puede contestar: ¿qué consume exactamente el tiempo en tu servidor?
4. Reducir carga de forma concreta
Lo que muestre el profiler determina la medida:
| El profiler muestra | Medida eficaz |
|---|---|
| Carga de chunks, generación de mundo | Bajar simulation-distance (predeterminado 10, mínimo 3): tiene más efecto que view-distance, porque solo los chunks simulados consumen tiempo de cálculo |
| Procesamiento de entidades | Limitar granjas de mobs, encerrar animales en vez de dejarlos sueltos, limpiar acumulaciones de ítems |
| Redstone / ticks de bloques | Construir relojes de Redstone con observadores en vez de bucles de repetidores, apagar mecanismos que corren todo el tiempo |
| Un solo plugin o una mod | Desactivarlo temporalmente y volver a medir; buscar una alternativa o una versión más reciente |
| Garbage Collection | Ahora más RAM es la respuesta correcta; antes no |
El último punto es importante: la RAM solo arregla un problema de memoria. Si un reloj de Redstone se está comiendo el tiempo de tick, un plan más grande no hará que el servidor vaya más rápido. Nuestro calculador de RAM para Minecraft te calcula cuánta memoria encaja con tu número de jugadores y el tamaño de tu modpack.
5. max-tick-time: la excepción, no la solución
El valor está en server.properties y define a partir de qué duración de tick interviene el Watchdog. El estándar son 60000 milisegundos, es decir, 60 segundos. Si se supera el valor, el servidor se cierra a sí mismo.
Muchas guías en internet recomiendan en este punto desactivar el Watchdog con -1. No lo uses como solución estándar. El Watchdog es la única instancia integrada que siquiera detecta un deadlock real. Con -1, un servidor muerto puede quedarse durante horas en el puerto: los jugadores no entran, nada en el log explica por qué y nadie recibe una alerta. Has quitado el indicador, no el problema.
Solo hay una buena razón para aumentarlo: un proceso conocido tarda legítimamente mucho. El caso clásico es el primer arranque de un modpack grande, donde la generación de mundo y la inicialización de mods pasan juntas más de un minuto en un tick. Entonces un valor como 180000 (tres minutos) puede ser razonable, temporalmente y con la intención de volver a bajarlo tras el primer arranque correcto.
Si Exception in server tick loop aparece en el log
Este mensaje es el más sencillo de los tres, porque trae su causa consigo. Justo debajo, o unas pocas líneas después, aparece una línea Caused by:; ahí está el error real, normalmente con el nombre de la mod o del plugin responsable.
Procedimiento:
- Buscar
Caused by:y anotar el nombre de la clase. - Si contiene el nombre de una mod o de un plugin, el causante queda identificado.
- Si el error apareció después de un cambio (nueva mod, actualización, nuevo mundo), deshaz primero ese cambio.
- Si el error sigue sin estar claro, envía toda la sección al soporte, con la hora.
El análisis de consola de tu servidor reconoce estas líneas automáticamente y explica cada mensaje detectado en texto claro, incluida la frecuencia. Si solo tienes un fragmento de log de otro sitio, puedes pegarlo en nuestro analizador de crash reports de Minecraft, incluso sin tener un servidor con nosotros.
Qué hacemos automáticamente por ti
- Medición de rendimiento sin que tengas que hacer nada. Los TPS se registran cada unos cinco minutos y se muestran durante 24 horas en el panel; no tienes que instalar ningún plugin.
- Aviso si el rendimiento se mantiene bajo. Si el rendimiento queda bajo durante una ventana significativa, se te avisa en vez de obligarte a detectarlo tú.
- Líneas de log explicadas. Los mensajes reconocidos reciben causa y solución en texto claro, en tu idioma, y cuando existe una guía adecuada, un enlace hacia ella.
- Regla de síntoma antes que causa. Si en la misma sección del log hay un mensaje de error más significativo que el cierre por Watchdog, te mostramos ese.
Solución de problemas: síntoma, comprobación, solución
| Síntoma | Comprobación | Solución probable |
|---|---|---|
| Lag solo al explorar zonas nuevas | ¿Ocurre cuando los jugadores entran en terreno inexplorado? | Generación de mundo; bajar simulation-distance, pregenerar el mundo |
| Lag a horas fijas | Comparar la hora con tareas programadas | Mover la copia de seguridad o el plan de reinicio a otra hora |
| El servidor se detiene sin error, el log termina de golpe | ¿Aparece A single server tick took al final? |
Cierre por Watchdog; leer el minuto anterior |
| Los TPS muestran 20, pero aun así va a tirones | /spark tps: revisar MSPT |
El limitador de TPS oculta la carga; decidir según MSPT |
| Después de añadir una mod | Quitar la mod y volver a medir | Conflicto de mods o mod con mucha carga |
| Dientes de sierra en el historial de TPS | Revisar Garbage Collection en el profiler | Presión de memoria; aumentar RAM |
| «Dispatched async TPS command» en el log | Solo esa línea, lo demás normal | Nada que hacer: es nuestra medición |
FAQ
¿A partir de qué valor de TPS notan algo los jugadores?
Hasta unos 18 TPS no se nota nada en el juego. Por debajo de 15 empieza a sentirse pesado. Pero no te fíes solo de eso: revisa también MSPT, porque el limitador de TPS puede mostrar un número sano mientras el servidor ya trabaja al límite.
¿Más RAM ayuda contra el lag?
Solo si la memoria es realmente el cuello de botella. Si el profiler muestra Garbage Collection como el principal consumo, sí. Si muestra un reloj de Redstone o una granja de mobs, más RAM no cambia nada. Mide primero, compra después.
¿Debo desactivar el Watchdog?
No, no de forma permanente. -1 te quita la única detección automática de una congelación real. Un aumento temporal de max-tick-time para un proceso lento conocido, como el primer arranque de un modpack, puede tener sentido; después, restablécelo.
¿Por qué aparece el aviso del Watchdog después de «Stopping server»?
Porque el servidor ya se estaba apagando y se quedó colgado durante ese proceso. Entonces el Watchdog limpió un cierre bloqueado; no mató un servidor en ejecución. La causa está antes de Stopping server.
¿Ayuda reiniciar?
Contra un retraso puntual, sí; contra la causa, no. Si el lag vuelve poco después de cada reinicio, es estructural: entonces solo avanzarás midiendo.
¿Cuál es la diferencia entre view-distance y simulation-distance?
view-distance define hasta dónde ven los jugadores; simulation-distance define hasta dónde se calcula realmente el mundo. Ambos valores están por defecto en 10 chunks. Como solo los chunks simulados consumen tiempo de cálculo, bajar simulation-distance alivia más con menos pérdida visible.
Si sigue habiendo lag
Antes de contactar con soporte, reúne tres cosas: la hora exacta del último incidente, el enlace de tu informe del profiler de spark y qué mods o plugins se añadieron por última vez. Con eso se puede revisar directamente la sección adecuada del log, en vez de hacer una ronda genérica de optimización.
Los ajustes generales para todos los juegos, como planes de reinicio, elección de tarifa y red, los encuentras en la guía mejorar el rendimiento de un gameserver. Cómo instalar y quitar mods y plugins correctamente está explicado en instalar mods y plugins de Minecraft.
¿Quieres un servidor con medición de TPS, explicación de logs y avisos incluidos sin trabajo extra? En alquilar un servidor de Minecraft encuentras las tarifas adecuadas.
Fuentes y banco de pruebas
max-tick-time, tasa de ticks y distancias: PaperMC — server.properties. Documenta el valor estándar de 60000 milisegundos, el cierre forzado al superarlo, la desactivación con-1y los valores estándar 10 paraview-distanceysimulation-distance.- spark está incluido en Paper: PaperMC — Profiling. Desde Paper 1.21 no hace falta una descarga separada.
- MSPT antes que TPS: spark — TPS and MSPT. Explica por qué el limitador de TPS puede mostrar 20 perfectos mientras el servidor en realidad va más lento.
- Comandos del profiler: spark — Command Usage. Fuente para
/spark profiler start --timeout <sekunden>y/spark profiler stop.
Banco de pruebas: 24 de agosto de 2026. Los valores estándar y los comandos pueden cambiar con nuevas versiones del servidor; si tienes dudas, consulta la documentación del fabricante enlazada.