Funktionen
Stündlicher Check
Eine Anfrage pro Stunde hält Salts, Berichte, Aufbewahrung und Tagessummen aktuell.
Einmal pro Stunde erzeugt Runlight den neuen Salt des Tages zum Zählen der Besucher und löscht die alten. Derselbe Lauf verschickt fällige E-Mail-Berichte und löscht Besuche, die älter sind, als eine Website sie behält. Außerdem summiert er jeden abgeschlossenen Tag auf, damit lange Zeiträume schnell laden. Diese Pflege passiert, wenn etwas den Check aufruft.
bash
curl -X POST https://example.com/runlight/api/check -H "Authorization: Bearer $CRON_SECRET"Der Check nimmt GET oder POST an, mit CRON_SECRET (oder dem Dashboard-Token) als Bearer-Token. Ihn öfter aufzurufen schadet nicht.
Besuche werden auch ohne den Check richtig gezählt, weil der erste Besuch des Tages ebenfalls den Salt erzeugt. Ohne ihn gehen aber keine Berichte raus, und Besuche jenseits der Aufbewahrungsdauer einer Website bleiben erhalten. Lange Zeiträume bleiben dann auch langsamer, weil sie jeden einzelnen Besuch lesen.
Vercel
Setze CRON_SECRET in den Umgebungsvariablen des Projekts und füge dann den Cron zu vercel.json hinzu.
vercel.json
{
"crons": [{ "path": "/runlight/api/check", "schedule": "0 * * * *" }]
}Vercel ruft ihn mit GET und dem Secret als Bearer-Token auf, und genau das erwartet Runlight.
Überall sonst
Jeder Scheduler, der eine HTTPS-Anfrage stellen kann, funktioniert, etwa eine Zeile in der crontab, GitHub Actions, Cloudflare Cron Triggers oder der Scheduler deiner Plattform.
bash
0 * * * * curl -fsS -X POST https://example.com/runlight/api/check -H "Authorization: Bearer YOUR_CRON_SECRET" > /dev/nullDu kannst auch await rl.check() aus Code aufrufen, der bei dir ohnehin per Timer läuft. Die Seite jeder Sprache zeigt ihren eigenen Weg, den Check auszuführen, etwa bin/rails runlight:check in Rails oder einen Hosted Service in .NET. Die eigenständigen Server führen ihn alle fünf Minuten selbst aus.