Workflows
Check scheduled GitHub Actions runs separately from the age of published data. Refresh only reads statuses and timestamp metadata; it does not run collectors or update datasets.
About these scheduled workflows
Several pages on this site display data that has to stay current: Azure and AWS release notes, Microsoft 365 roadmap items, RSS headlines, and the published IP ranges for Azure and GitHub. Each is refreshed by a scheduled GitHub Actions workflow, and this page reports the state of every one of them.
How the refresh works
- A workflow runs on a cron schedule, fetches the upstream source, and writes the result as static JSON into the repository.
- A successful data-refresh workflow triggers the deployment workflow. Dataset pages serve the resulting static files; this status page separately queries GitHub when opened or refreshed.
- Because the output is static, pages stay fast and keep working even when an upstream source is temporarily unavailable.
Why show the status
A successful run is not proof that every published dataset is current. Run status and dataset collection timestamps are therefore shown separately. The last successful run is searched only within the latest 100 repository runs on main; an absent result does not mean the workflow has never succeeded.
Freshness uses the oldest required dataset's recorded generatedAt, not its commit time or deployment date. The alert threshold is the largest scheduled gap plus half that gap, capped at 12 hours of grace (36 hours for a daily job). Missing, unsupported or future timestamps remain unknown. This is an operational indicator, not an availability guarantee.
Run statuses are checked once when this page opens. Refresh statuses retries the lookup; there is no automatic minute-by-minute polling. Network, GitHub access and public API quota failures are reported as unavailable, not as failed workflow runs.
Scheduled times, not guaranteed start times
The catalog includes every cron-triggered workflow, including the weekly favicon refresh. Schedules are generated from the repository's workflow YAML files at each deployment, so they remain available even when GitHub run details cannot be loaded.
Each schedule shows the selected timezone and the original UTC time. Your browser's timezone is the default; Europe/Paris and UTC are also available. Times and weekdays refer to the next scheduled occurrence, taking daylight saving time into account; expand the run details, then Cron details, to see that date and the source expression. A local time may change when the clocks change, while the UTC schedule stays the same.
GitHub Actions can delay scheduled runs, and a disabled workflow will not run. These are planned trigger times, not a promise that a job starts immediately. Started reports the actual start of the latest run, which may also have been triggered manually.