O que eu rodo antes de dormir

Toda noite, antes de fechar meu laptop, eu rodo um comando. Ele verifica 15.000 páginas no meu site de produção: cada post de blog, cada página de empresa, cada guia programático, cada variante de locale. Para cada página, ele verifica o status HTTP, mede o TTFB, confere o status do cache do Cloudflare e registra qualquer erro. A verificação completa leva cerca de 6 horas. Ela roda em segundo plano enquanto eu durmo.

Também rodo uma verificação rápida de caminho crítico que termina em 2 minutos: endpoints de saúde, sitemaps, páginas de receita, hubs de empresas S-tier, páginas de mercado, índices de conteúdo programático, arquivos de blog i18n. Essa eu acompanho. Se algo falha, eu investigo antes de dormir.

A rotina produz um relatório assim:

NIGHTCHECK -- 2026-03-27 (morning)
Overnight comprehensive: 16,228/16,602 ok (97.7%)
Avg TTFB: 715ms
S-tier companies: ALL PASS, ALL HIT
Markets: ALL PASS (89-175ms HIT)
i18n blogs: es 95ms HIT | ja 196ms HIT | de 181ms HIT

Ninguém me pede para fazer isso. Nenhum ticket exige. Nenhum sprint inclui “rodar nightcheck”. A rotina existe porque eu me importo se o site funciona quando eu não estou olhando para ele.

Por que toda noite

O site muda todo dia. Em um único dia, posso fazer deploy de 87 commits: traduções i18n, atualizações de provedores de crawl, experimentos de CRO, correções de performance, remediações de logo. Cada commit é testado individualmente. Mas a composição de 87 commits pode produzir falhas que nenhum commit individual revela.

Um lote de tradução pode empurrar o sitemap do blog além de um limite de renderização. Um novo provedor pode introduzir uma página de empresa que leva 14 segundos para renderizar. Uma mudança de header de cache pode fazer o Cloudflare parar de cachear uma rota que antes era rápida. Um refactor de CSS pode quebrar um template em um locale mas não em outros.

O nightcheck captura falhas de composição. Não “esse commit quebrou algo?”, mas “o site funciona depois de tudo que foi para produção hoje?”. A distinção importa porque falhas de composição são invisíveis no CI. Cada commit passa nos seus próprios testes. O comportamento agregado de 87 commits passando nos seus próprios testes não garante que o sistema agregado funcione.

O que é medido

A verificação tem quatro níveis:

P0 Infraestrutura. O endpoint de saúde retorna saudável com banco de dados conectado. Sitemaps retornam XML válido. Robots.txt e llms.txt estão presentes. O feed RSS é válido. São as coisas que, se quebradas, tornam o site invisível para mecanismos de busca.

P0 Receita. Homepage, construtor de currículo, analisador e página de preços carregam. São as páginas que, se quebradas, custam dinheiro diretamente. O construtor de currículo é historicamente a página mais lenta e recebe um limiar de WARN em 5 segundos.

P1 Superfície SEO. Arquivo do blog, páginas hub pilares, diretório de empresas, navegação de vagas, todos os cinco índices de conteúdo programático (guias de currículo, guias de salário, guias de carta de apresentação, perguntas de entrevista, palavras-chave ATS), quatro amostras de blog i18n e todos os 20 hubs de empresas S-tier. São as páginas que geram tráfego orgânico. Um 404 na página do Google é um incidente de SEO.

P2 Abrangente. Toda URL nos sitemaps de blog e empresas. Essa é a verificação de fundo de 6 horas. Ela captura as falhas de cauda longa: um único post de blog que retorna 500 por causa de uma citação malformada, uma página de empresa que dá timeout por causa de uma query N+1 em uma empresa grande.

Cada página é verificada com curl usando um header User-Agent realista. Curl puro recebe 403 do Cloudflare. O header de status de cache é capturado junto com o status HTTP e o TTFB. Uma página pode retornar 200 mas mostrar DYNAMIC quando deveria ser HIT, o que significa que a regra de cache está mal configurada. A medição de TTFB é a latência real do lado do servidor, não o tempo de renderização do navegador.

A tendência de TTFB

Eu rodo essa verificação desde março de 2026. A tendência de TTFB conta a história da performance:

A tendência captura a jornada de performance das páginas de mercado: o purge de cache expôs o problema (14,3s), o cache na edge mascarou (89-175ms HIT), a correção na forma da query resolveu a causa raiz (108ms na origem). Sem a tendência noturna, eu teria acreditado que o cache na edge era a solução. As medições de TTFB provaram que o render na origem ainda era lento durante a revalidação, o que justificou o refactor da query.

O nightcheck não corrigiu o problema de performance. Ele tornou o problema de performance mensurável, o que o tornou corrigível.

O que ninguém vê

A coisa mais valiosa do nightcheck é que ele roda quando ninguém está olhando. Não existe notificação no Slack para “16.228 páginas passaram durante a noite”. Não existe dashboard que fica verde. O relatório existe em um arquivo de log que eu leio tomando café na manhã seguinte.

A ausência de cerimônia é o ponto. O nightcheck não é qualidade performática. Não é uma métrica para uma daily. É uma disciplina privada: tudo funcionou enquanto eu dormia? Se sim, ótimo. Se não, eu sei exatamente o que falhou e quando.

A disciplina se acumula. A verificação de cada noite estabelece uma baseline para a comparação do dia seguinte. Um aumento de 50ms no TTFB de uma página específica dispara uma investigação — não porque 50ms importa para os usuários, mas porque o aumento indica que algo mudou. Talvez uma nova dependência adicionou latência. Talvez uma regra de cache expirou. Talvez uma query do banco de dados cresceu com o dataset. A baseline noturna torna a degradação visível antes que ela se torne um problema.

Isso é contexto composto aplicado a operações. Cada verificação noturna deposita um ponto de dado. Os pontos de dado se acumulam em uma tendência. A tendência torna visíveis problemas que nenhuma verificação isolada revelaria.

A rotina é o padrão

Eu poderia automatizar o nightcheck em um cron job e olhar um dashboard. Eu escolho rodar manualmente porque o ato de rodar mantém o hábito de se importar. No momento em que a verificação se torna trabalho de outra pessoa, ou uma notificação que eu dispenso, ou um dashboard que eu paro de olhar, o padrão se deteriora.

O padrão não é “o site passa em verificações automatizadas”. O padrão é “eu pessoalmente verifiquei que o site funciona antes de ir dormir”. A diferença é responsabilização. Uma verificação automatizada que falha silenciosamente é um bug na automação. Uma verificação manual que eu pulo é uma escolha que eu fiz sobre o que me importa.

Eu rodo toda noite porque a alternativa é confiar que tudo ainda funciona. Confiança sem verificação é esperança. Esperança não é estratégia de operações.

FAQ

Quanto tempo leva a verificação completa?

A verificação rápida de caminho crítico leva 2-3 minutos (36 páginas com medição de TTFB e cache). A verificação abrangente do sitemap leva 5-7 horas (mais de 15.000 páginas). A verificação rápida roda de forma síncrona; a abrangente roda em segundo plano.

Por que não usar um serviço de monitoramento de uptime?

Serviços de uptime verificam se uma página retorna 200. O nightcheck verifica se uma página retorna 200 com o status de cache correto, TTFB aceitável e estrutura de conteúdo esperada. Uma página que retorna 200 mas leva 14 segundos com cache DYNAMIC está tecnicamente no ar e operacionalmente quebrada.

O que acontece quando algo falha?

Eu investigo antes de dormir se a falha é em uma página de receita ou infraestrutura. Para falhas na verificação abrangente, eu reviso o log na manhã seguinte e priorizo por tipo de página. Um post de blog falhando tem prioridade menor que um hub de empresa falhando. Um cache DYNAMIC em uma página de alto tráfego tem prioridade maior que um TTFB lento em uma página de baixo tráfego.

Isso escala?

15.000 páginas é a escala atual. A verificação abrangente é limitada por I/O (requisições curl sequenciais), não por computação. Dobrar a quantidade de páginas dobra o tempo de execução. Com 30.000 páginas, a verificação levaria 12 horas, o que ainda cabe em uma janela noturna. Além disso, seria necessário verificação paralela com rate limiting.