GitHub Actions Scheduled Workflows: Refresh a Museum Catalog Without Assuming Cron Always Runs

A Cron Expression Is a Request, Not a Completion Record

A museum automatically rebuilds its public event catalog each morning. A GitHub Actions workflow fetches reviewed listings, runs accessibility checks and prepares a static site preview. Editors assume that if the YAML file says 8:30 AM, the refresh always happened before the gallery opened. GitHub warns that scheduled workflow events can be delayed under high load and, at some times, dropped. The operator should verify an actual successful run and its data revision rather than treating the cron configuration as evidence. A missed build may leave stale events on the public site even though the repository contains new listings. Separating schedule intent, job start, successful artifact and editorial approval keeps the publishing process understandable.

Specify the Time Zone the Staff Actually Mean

Scheduled workflows use POSIX cron syntax. GitHub documentation says schedules default to UTC and now allow an optional IANA time zone identifier, such as America/New_York, when local-time behavior is required. A local schedule must be tested against daylight saving transitions, including missing spring-forward hours. Staff should write the desired local day and time into the workflow’s documentation, not only the cron expression. For a museum with volunteers in multiple time zones, the responsible operator’s time zone is more meaningful than the hosting region. Verify that the project uses syntax supported by its current GitHub environment and avoid casually translating a local time into a fixed UTC offset that becomes wrong in another season.

Understand What a Scheduled Event Can Trigger

GitHub states that scheduled workflows run on the latest commit of the default branch and that the workflow file must be on that branch. The minimum supported interval is five minutes, but frequent runs are not a guarantee of punctual execution. A schedule can also stop working when its associated actor is suspended, removed or deprovisioned, according to GitHub troubleshooting documentation. Repositories may have other conditions affecting runs, including repository state and action policy. Check the actual trigger, commit SHA, actor and execution time when investigating an absent update. Do not assume that a failed or missing schedule will be replayed automatically; design a separate recovery procedure that respects approvals.

Keep the Job Idempotent and the Source Revision Explicit

A catalog rebuild should name the approved source revision and record the generated artifact’s digest. If the same approved data is processed twice, the workflow should produce an equivalent reviewable output without duplicating announcements or automatically publishing entries. A job that downloads the newest spreadsheet without recording its revision can change content on rerun, even when the cron event has not changed. Store build provenance in CI artifacts or an internal status log without placing private records in public output. A separate approval process should decide when to publish the newly generated catalog. The scheduled job can stage a candidate, but it should not treat a green build as evidence that opening hours, access notes or permissions are accurate.

Avoid Top-of-the-Hour Congestion and Silent Failures

GitHub notes that scheduled events often experience high load at the beginning of the hour and recommends scheduling at other minutes to reduce delay risk. Choosing a less crowded minute helps but does not create a service-level punctuality guarantee. For a public calendar, define a freshness threshold such as whether the latest approved build was completed within the museum’s required review window. Monitor both the absence of a run and the absence of a successful, approved output. Include a visible alert to a named operator when the threshold is missed. A workflow that started but failed, a workflow that finished successfully with outdated input and a workflow that never started require different responses.

Compare an On-Time Refresh, Delay and Missing Run

A conceptual timeline can show three states. First, a scheduled event starts, builds against the expected source revision and yields a reviewable artifact. Second, execution starts later than intended, so the public catalog may remain stale during opening hours. Third, no run appears for the expected window, requiring a manual investigation or a controlled workflow_dispatch run. These states are illustrations, not measured GitHub performance. On-time technical success is still not permission to publish the artifact. Operators should compare workflow conclusion, source revision and sign-off state. Track whether a manual rerun collides with a later scheduled run, and prevent two jobs from overwriting each other’s reviewed outputs.

Make Recovery Safe for Volunteers and Editors

A runbook should identify the owner who can inspect Actions history, the approved data source, the allowed manual trigger, and any environment approvals. For a missing refresh, check the workflow file on the default branch, the cron schedule, the actor’s status, action policies and recent Actions service incidents. For a failed refresh, inspect test reports without uploading sensitive attendee lists as artifacts. If a current approved catalog is already live, leave it available while investigating rather than publishing an unreviewed replacement. A retry should use the same recorded input revision or deliberately document a new revision. Avoid automatic user-facing emails tied directly to an uncertain scheduled event.

Exercise Clock and Failure Boundaries in Staging

Create a harmless test repository or an isolated branch using synthetic event data. Validate the syntax in the actual workflow environment, check the requested IANA time zone, and calculate how daylight saving changes affect the intended schedule. Test a manual trigger, an unchanged source revision, a simulated failed build and a case where no successful run occurs before the freshness deadline. The workflow should notify an operator but never bypass the approval gate. This guide did not configure or run a GitHub repository, and no schedule reliability measurements were made. Treat the proposed timeline as a QA plan, not a claim that a specific cron job was delayed or dropped.

Release Only a Verified Catalog Version

For every public update, retain the source commit or revision, successful build identifier, artifact digest, editorial reviewer and publication timestamp. Publish only when all required checks and human approvals match that exact artifact. When a scheduled build is late, show the existing approved catalog with a clearly maintained update policy; do not conceal its age by changing the displayed timestamp. Review stale data alerts after every missed run and after changes to the default branch or workflow actor. The most useful success metric is not the number of cron events configured, but the share of required catalog refreshes that were verified and approved before their operational deadline.

Related guides

• GitHub Actions workflow_run: Keep Untrusted Test Artifacts Out of a Release Job
• GitHub Actions workflow_dispatch Inputs: Require a Reviewed Museum Catalog Export
• GitHub Actions workflow_call Inputs: Validate Museum Preview Settings Before CI Runs

How We Research

For this guide, we reviewed the official product documentation on November 8, 2026: GitHub events that trigger workflows, GitHub workflow syntax on.schedule, GitHub troubleshooting workflows. We checked the named setting or feature against its published behavior, mapped the documented constraints to the specific hypothetical scenario, and reviewed whether the topic duplicated titles in the supplied LabFin WordPress inventory or prior B0267–B0276 ZIPs. No authenticated vendor service was run; we did not perform a benchmark, observe real customer data, verify third-party rights or claim operational outcomes. All illustrated records and comparisons are teaching examples. Confirm product documentation and security requirements again before implementing a workflow in a real organization.

Frequently Asked Questions