Seu container está com o relogio errado (e você não sabe)

Toda segunda-feira às 8h da manhã, a equipe recebia um tsunami de tickets de "não consigo logar".

O sistema de autenticação estava quebrando religiosamente, toda segunda-feira.

Depois de 3 semanas investigando, encontrei o culpado:

O JWT tinha expiresIn: "7d", parecia correto, né?

Mas o relógio do servidor de autenticação estava 3 minutos adiantado.

E o servidor que validava os tokens? Com o relógio correto.

Resultado: o token expirava antes de deveria. E a diferença foi acumulando com o drift do relógio.

Toda segunda-feira, o acumulado de 7 dias de drift ultrapassava o threshold de tolerância.

Usuários bloqueados. Help desk sobrecarregado. Time de DevOps no modo DETETIVE.

A solução foi simples, mas ninguém pensou nela antes:

1. Sincronizar NTP com chronyd dentro do container, porque container sem NTP é uma bomba relógio
2. Middleware de refresh com margem de 5 minutos antes da expiração, o token renovava antes de vencer, eliminando a janela de falha.
3. Monitoramento de drift de relógio entre servidores — se a diferença passar de 1 minuto, alerta automático.

A moral da história?

Às vezes o bug não está no código. Está na infraestrutura que sustenta o código.

Nós revisamos o JWT, testamos a lógica de expiração, validamos o fluxo de refresh. Tudo parecia perfeito.

O problema estava em algo que ninguém olhou: o relógio do container.

Você já perdeu horas debugando algo que parecia código, mas era infraestrutura?

Feito!