The Check production availability GitHub workflow checks the public site at
minutes 7, 22, 37 and 52 of every hour. It uses Node 24 without installing
dependencies, deploying anything, or accessing Cloudflare credentials.
The checks cover the Astro home and download pages, a classic URL redirect
with its query string, the users archive, robots rules, the documentation
sitemap, latest and versioned reference URLs, and PDF headers plus a 16-byte
range. When the selected production DOC_REVISIONS entry is present, they also
check the modeling manual and its search JavaScript. Version and revision come
from workers/docs/wrangler.jsonc; update that configuration when promoting
documentation. Each run makes ten requests, or twelve with the modeling manual,
and caps each response read at 1 MB. It never downloads the complete PDF.
Transient failures get two retries, twenty seconds apart. Persistent failures fail the workflow and leave the failing path in its log. Check the failed path, the latest Pages and Worker deployments, and Cloudflare Workers logs. A version or revision mismatch can mean the checked-in promotion has not reached production yet. Use the deployment runbook for rollback; this workflow never changes traffic automatically.
From the website checkout:
node scripts/check-availability.mjs
gh workflow run availability.yml --repo Gecode/gecode.github.io --ref main
gh run list --repo Gecode/gecode.github.io --workflow availability.yml --limit 5Use scripts/docs/smoke-worker.mjs for the broader documentation checks after a
deployment. The scheduled checks deliberately use a smaller request set.
The responsible maintainer must enable GitHub Actions email or web notifications and select failed workflows only. Scheduled-run notifications go to the user who created or last changed the schedule, or who re-enabled it. Repository workflow success alone does not establish that anyone receives failure alerts. Confirm that maintainer's settings before relying on this workflow. See GitHub workflow notifications.
On 5 September 2026, the authenticated zayenz account's settings were checked:
Actions email notifications were enabled for failed workflows only. Keep that
account as the schedule owner, or verify the replacement owner's settings.
GitHub schedules can be delayed or dropped under load. Public-repository schedules are automatically disabled after sixty days without repository activity. Check that this workflow remains enabled during routine maintenance; re-enable it when necessary. This is a periodic availability check, with no guaranteed detection time, and cannot detect every regional or intermittent failure. See GitHub schedule limitations.
Cloudflare's budget notification remains separate from availability monitoring. A passive origin alert can complement these checks, but it does not cover every failure generated by the documentation Worker or R2. A Workers Observability notification also needs an actual alert rule; the notification destination alone does not monitor errors.
The email Worker waits for every configured forward to finish and reports any forwarding failure. Native Worker logging is enabled; the handler does not log message bodies. Deploy it separately from the website and documentation:
gh workflow run workers.yml --repo Gecode/gecode.github.io --ref main \
-f operation=deploy -f environment=production -f worker=emailThe routing tests cover address selection and partial forwarding failure. They do not establish inbox delivery. Use Cloudflare Email Routing delivery analytics for that check; its zone-level Analytics Read permission is separate from the website deployment token. A failed availability run does not diagnose mail delivery, because the public HTTP checks exercise only the website.