A opção pause-when-empty-seconds em server.properties define quanto tempo o servidor deve esperar sem jogadores antes de pausar. A documentação atual informa que a pausa está desativada por padrão, pois pode ser incompatível com o que plugins esperam quando não há ninguém online. Isso torna a opção uma decisão de compatibilidade, não um simples modo de economizar CPU.

Plugins podem depender de scheduler, tarefas periódicas, conexões externas, limpeza, backups, eventos ou relógios do servidor mesmo sem jogadores. Antes de ativar pausa, inventarie dependências e teste retomada em uma cópia da instalação.

Separe pausa, shutdown e servidor vazio

Pausar não é encerrar o processo. Um shutdown gracioso chama rotinas de desligamento de plugins, fecha conexões e salva dados conforme sequência. Pausa muda operação enquanto processo continua ativo. Não presuma que backup, autosave ou tarefas programadas funcionam igual durante pause.

O servidor pode ficar vazio após desconexão, mas proxy, bot ou plugin de teleporte pode tentar conectar depois. Teste como a instância retoma: primeira conexão, carregamento de mundo, mensagens, permissões e tarefas atrasadas. Verifique se proxy marca backend como saudável durante pause.

Não use esse parâmetro para substituir scheduler de hospedagem, desligamento automático ou gerenciamento de container. Cada sistema tem comportamento de recuperação e política de dados diferente.

Inventarie plugins e rotinas

Liste plugins com tarefas periódicas: backup, economia, reinício, ranking, banco, Discord, loja, scoreboard e limpeza. Consulte documentação e autores para confirmar suporte a pause. Um plugin pode esperar ticks, e relógio de ticks deixa de avançar como imaginado em pause.

Identifique serviços externos que dependem de heartbeat ou conexão contínua. Um bot pode considerar o servidor offline; outro pode manter socket e deixar estado de presença desatualizado. Teste endpoints usando ambiente separado e credenciais fictícias.

Revise jobs do sistema operacional, host e painel que esperam o processo ativo ou enviam comandos. Se algum componente faz health check e tenta restart quando servidor pausa, haverá ciclo inesperado.

Calcule economia com dados

Meça uso de CPU e energia quando vazio, custo de manter processo ativo e economia provável da pausa. Se servidor é dedicado e tem outras instâncias, uso baixo de Paper pode não mudar consumo físico. Se painel cobra por runtime, confira contrato e comportamento de billing em vez de supor.

Compare alternativa simples: diminuir tarefas cosméticas, mover monitoramento, agendar shutdown em horário sem atividade ou usar servidor sob demanda. Pondere tempo de primeira conexão e risco de plugin. A pausa só compensa se economia e retomada atenderem a comunidade.

Não reduza monitoramento junto com pausa. Mantenha alerta externo que distingue processo ativo pausado de indisponibilidade real, e canal para equipe retomar serviço.

Teste em staging

Duplique Paper, plugins, config e dados para uma cópia. Desative endpoints de produção e use banco fictício. Configure valor curto para reproduzir, espere servidor pausar e observe CPU, scheduler, console e métricas. Reconecte conta teste e valide estado.

Teste ciclos repetidos vazio/cheio, passagem pelo proxy, tarefa agendada durante pausa, backup e restart. Confirme que nenhum plugin perde evento ou executa várias tarefas acumuladas de uma vez ao retomar.

Se plugin não documenta suporte, trate como risco de compatibilidade e reporte ao autor com passos mínimos. Não conclua compatibilidade só porque o processo reiniciou ou jogador entrou.

Implemente com observabilidade

Faça backup do arquivo e registre valor anterior. Aplique num ambiente controlado e monitore logs por pelo menos vários ciclos. O painel deve mostrar estado compreensível e alertas não devem interpretar pause como crash.

Defina tempo de retomada aceitável, carga ao reconectar muitos jogadores e comportamento em horário de evento. Se a primeira conexão demora, exiba mensagem ou mantenha lobby ativo que consiga acordar backend com fluxo suportado.

Se pause cria inconsistência, backlog de tarefas ou falsa falha de proxy, reverta ao padrão e resolva componente de forma separada. Não aumente timeout de toda a rede só para acomodar uma opção que não foi testada.

Comunique a experiência

Informe que o servidor pode levar alguns instantes para acordar depois de período sem usuários. Explique se o status público pode parecer offline e qual modo permanece disponível. Dê à equipe canal para forçar retomada em evento ou manutenção.

Evite surpresa para jogadores que agendam tarefa, stream ou evento. Faça janela de teste com staff, observe feedback e mantenha rollback rápido.

Se o objetivo é economizar recursos, acompanhe métrica real e custo depois de publicar. Compare com período equivalente antes e documente economia, impacto em login e falhas.

Revise após atualizações

Atualizações de Paper e plugins podem modificar scheduler e compatibilidade. Refaça teste depois de upgrade, adição de plugin ou troca de proxy. Remova o ajuste se não há ganho comprovado.

Pause-when-empty pode reduzir atividade em cenários compatíveis, mas deve ser implantado somente depois de avaliar tarefas, health checks e retomada. O aviso do Paper sobre incompatibilidade com expectativas de plugins merece tratamento prático em staging.

Defina responsabilidades de operação

Determine quem pode acordar o servidor, como forçar retorno em evento e que alerta significa pausa esperada. A equipe precisa distinguir estado pausado de falha. Documente mensagem para jogadores, tempo de retomada e contato para ocorrência.

Se host executa atualizações automáticas, confirme como pause interage com manutenção agendada. O processo pode estar vivo e não carregar plugin novo até retomada, ou painel pode entender o status incorretamente. Teste ciclo com janela de atualização na cópia.

Revise política de cobrança do provedor. Nem toda hospedagem suspende faturamento por pausa, e reduzir CPU pode não liberar memória ou armazenamento. Baseie a decisão em contrato e métricas.

Proteja dados e sessões de jogador

Antes de pausar, assegure autosave e backup segundo a estratégia existente. Teste saída rápida, relogin e persistência de inventário. Se plugin mantém estado em memória não persistido, pause pode preservar processo mas uma falha subsequente ainda perder estado.

Verifique que banco de dados mantém conexão ou reconecta corretamente depois. Pool expirado pode fazer primeira ação do jogador falhar após pausa. Observe logs de plugin e conexão com serviço externo na retomada.

Faça ensaio de contingência em que instância não acorda; equipe deve saber como reiniciar, coletar log e restaurar backup. Não dependa de um só painel ou operador.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.