An annual scheduled-workflow review should prove three things: the job still needs to exist, its timing and permissions are correct, and a missed or repeated run can be detected and recovered safely. Use evidence from recent runs and a controlled recovery exercise rather than checking configuration alone.

Inventory every schedule and owner

List the workflow name, business purpose, owner, backup owner, repository or service, schedule expression, timezone, expected duration, downstream systems, notification route, and last successful run. Include schedules outside the main platform, such as database jobs and vendor automations. Retire duplicates and require an owner for every remaining entry. A job without a current consumer or responsible owner is a candidate for safe disabling after dependency review.

Verify timing and platform behavior

Translate each schedule into local calendar examples for normal time and daylight-saving transitions. Confirm which branch or deployed version executes. GitHub's scheduled workflow documentation says scheduled workflows run from the default branch and may be delayed or even dropped during heavy load, especially near the start of the hour. It also says public-repository schedules are automatically disabled after 60 days without repository activity. Those limits mean a cron expression is not, by itself, evidence that a critical task ran.

Cloudflare's Cron Trigger documentation says Cron Triggers execute on UTC and invoke a Worker's scheduled handler. For any platform, check timezone assumptions, version selection, and what happens when an execution overlaps the next trigger.

Check safe execution and recovery

For each workflow, answer these questions:

  1. Is the operation idempotent, or does a retry duplicate emails, charges, records, or publications?
  2. Is there a lock or deduplication key for overlapping runs?
  3. Are timeouts, retry limits, and backoff behavior explicit?
  4. Does a durable record show started, completed, failed, and skipped states?
  5. Can an operator rerun one missed period without replaying unrelated work?

Test one non-destructive recovery path. Pause a test dependency or use a fixture that causes a controlled failure, confirm the alert, restore the dependency, and execute the documented replay. Record the outcome and update the runbook.

Review access, dependencies, and cost

Remove unused secrets and permissions, rotate credentials only through the approved security process, and confirm that the workflow uses the least access it needs. Check API versions, runtime versions, billing limits, quotas, data retention, and vendor ownership. Compare actual execution counts and costs with the expected schedule. A large gap can indicate missed runs, manual retries, or an undocumented second trigger.

Require observable acceptance evidence

Define one freshness signal for the produced data, one success record per run, and an alert when either is late. Dashboards are useful, but the acceptance check should verify the output that consumers rely on. Finish the review with an owner, dated decision, unresolved risks, and next review date. The workflow passes only when a recent run, a failure alert, and a recovery exercise all support the written design.

Sources

  1. Events That Trigger Workflows: Schedule — GitHub
  2. Cron Triggers — Cloudflare
  3. Troubleshooting Workflows — GitHub
  4. Disabling and Enabling a Workflow — GitHub

Related reading