Verificação agendada

Uma requisição por hora mantém em dia os salts, os relatórios, a retenção e os totais diários.

Uma vez por hora, o Runlight cria o novo salt do dia para contar visitantes e apaga os antigos. A mesma execução envia os relatórios por email que estiverem na hora e apaga as visitas mais antigas do que um site guarda. Ela também soma cada dia encerrado, para que períodos longos carreguem rápido. Essa manutenção acontece quando algo chama a verificação.

curl -X POST https://example.com/runlight/api/check -H "Authorization: Bearer $CRON_SECRET"

A verificação aceita GET ou POST, com CRON_SECRET (ou o token do painel) como bearer token. Chamá-la com mais frequência não faz mal.

As visitas são contadas corretamente sem a verificação, porque a primeira visita do dia também cria o salt. Sem ela, nenhum relatório sai e as visitas além da retenção de um site continuam guardadas. Os períodos longos também continuam mais lentos, já que leem cada visita.

Vercel

Defina CRON_SECRET no ambiente do projeto e depois adicione o cron ao vercel.json.

{
  "crons": [{ "path": "/runlight/api/check", "schedule": "0 * * * *" }]
}

A Vercel a chama com GET e o segredo como bearer token, que é o que o Runlight espera.

Em qualquer outro lugar

Qualquer agendador capaz de fazer uma requisição HTTPS funciona, incluindo uma linha no crontab, GitHub Actions, Cloudflare Cron Triggers ou o agendador da sua plataforma.

0 * * * * curl -fsS -X POST https://example.com/runlight/api/check -H "Authorization: Bearer YOUR_CRON_SECRET" > /dev/null

Você também pode chamar await rl.check() a partir de um código que já roda num timer. A página de cada linguagem mostra a forma dela de rodar a verificação, como bin/rails runlight:check no Rails ou um hosted service no .NET. Os servidores independentes a rodam sozinhos a cada cinco minutos.