Vérification planifiée

Une requête par heure tient à jour les sels, les rapports, la conservation et les totaux quotidiens.

Une fois par heure, Runlight crée le nouveau sel du jour pour compter les visiteurs et supprime les anciens. Le même passage envoie les rapports par e-mail qui sont dus et supprime les visites plus anciennes que ce qu’un site conserve. Il fait aussi le total de chaque journée terminée, pour que les longues périodes se chargent vite. Cet entretien a lieu quand quelque chose appelle la vérification.

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

La vérification accepte GET ou POST, avec CRON_SECRET (ou le jeton du tableau de bord) comme bearer token. L’appeler plus souvent ne fait aucun mal.

Les visites sont comptées correctement sans la vérification, car la première visite du jour crée aussi le sel. Sans elle, en revanche, aucun rapport ne part et les visites au-delà de la durée de conservation d’un site sont gardées. Les longues périodes restent aussi plus lentes, puisqu’elles lisent chaque visite.

Vercel

Définissez CRON_SECRET dans l’environnement du projet, puis ajoutez le cron à vercel.json.

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

Vercel l’appelle en GET avec le secret comme bearer token, ce que Runlight attend.

Partout ailleurs

N’importe quel planificateur capable de faire une requête HTTPS fera l’affaire, y compris une ligne de crontab, GitHub Actions, les Cloudflare Cron Triggers ou le planificateur de votre plateforme.

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

Vous pouvez aussi appeler await rl.check() depuis du code que vous exécutez déjà sur une minuterie. La page de chaque langage montre sa propre façon de lancer la vérification, comme bin/rails runlight:check dans Rails ou un hosted service en .NET. Les serveurs autonomes la lancent eux-mêmes toutes les cinq minutes.