One scheduled job. It calls GET /health on
reserve-gate.onrender.com every five
minutes between 23:30 and 09:00 UTC, so the free instance does not spin
down and a visitor does not pay a cold start.
Nothing else is here. No secrets, no tokens, no write access to anything. The
only network call in the repository is the curl in
.github/workflows/ping.yml.
reserve-gate already runs the same loop for the afternoon and evening shift,
and it works — three landings a day. But GitHub drops every one of its
scheduled attempts between 04:07 and 08:07 UTC: five in a row, on all five
days read out of gh run list on 21 Sept 2026. No cron change inside that
repository reaches the morning.
The working theory is that GitHub deprioritises scheduled runs per repository, so a repository that does nothing else gets its own turn. That is a guess. If the attempts below are dropped the same way, the cause is not per-repository and the answer is an external pinger on a fixed interval, not more GitHub cron.
Render grants 750 free instance hours per workspace per month and suspends every free service once they are gone, so the two repositories divide the day rather than both running all of it.
| Shift | UTC | IST | Owner |
|---|---|---|---|
| Morning | 23:30 – 09:00 | 05:00 – 14:30 | this repository |
| Afternoon and evening | 09:00 – 21:30 | 14:30 – 03:00 | reserve-gate |
| Asleep | 21:30 – 23:30 | 03:00 – 05:00 | nobody |
That is about 22 hours a day, roughly 682 instance hours in a 31-day month, which leaves 68 hours of margin under the cap.
A delayed run can land hours outside its shift, so the job checks the clock and exits 0 rather than spending hours the other shift has already paid for.
bash tools/shift-check.sh # 11 cases over the window arithmetic, exits non-zero on a miss
gh run list --workflow=ping.yml
curl -w "%{time_starttransfer}\n" -o /dev/null -s https://reserve-gate.onrender.com/healthtools/shift-check.sh replays the workflow's clock branch against an injected
time, including both edges, a delayed run outside the shift, and month and year
rollover. It caught one bug already, in itself rather than in the workflow:
GNU date reads the -1 in "23:30 -1 day" as a timezone offset and lands two
days out, so the day offsets are epoch arithmetic.
A green run proves one curl succeeded. It does not prove the pings continued —
open a run's log and confirm the lines are five minutes apart, to the shift's end.