Comprobación programada

Una petición por hora mantiene al día las sales, los informes, la retención y los totales diarios.

Una vez por hora, Runlight crea la nueva sal del día para contar visitantes y borra las antiguas. La misma ejecución envía los informes por email pendientes y borra las visitas más antiguas de lo que conserva un sitio. También suma cada día terminado, para que los rangos largos carguen rápido. Este mantenimiento ocurre cuando algo llama a la comprobación.

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

La comprobación acepta GET o POST, con CRON_SECRET (o el token del panel) como bearer token. Llamarla más a menudo no hace ningún daño.

Las visitas se cuentan bien sin la comprobación, porque la primera visita del día también crea la sal. Sin ella no sale ningún informe y se conservan las visitas que superan la retención de un sitio. Los rangos largos también siguen siendo más lentos, ya que leen cada visita.

Vercel

Define CRON_SECRET en el entorno del proyecto y añade el cron a vercel.json.

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

Vercel la llama con GET y el secreto como bearer token, que es lo que Runlight espera.

En cualquier otro lugar

Sirve cualquier programador de tareas que pueda hacer una petición HTTPS, como una línea de crontab, GitHub Actions, Cloudflare Cron Triggers o el programador de tu plataforma.

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

También puedes llamar a await rl.check() desde código que ya ejecutas con un temporizador. La página de cada lenguaje muestra su propia forma de ejecutar la comprobación, como bin/rails runlight:check en Rails o un hosted service en .NET. Los servidores independientes la ejecutan por sí solos cada cinco minutos.