I am troubleshooting native GitHub Actions scheduling in a private GitHub.com repository. Repository, commit and run identifiers are omitted from this public report. Can GitHub staff advise how to investigate schedule registration or arrange a private diagnostic channel?

On 2 November 2026, the repository-wide Actions runs API returned zero runs with event=schedule through 17:46 UTC (18:46 CET). Manual and push-triggered runs succeeded. An initial 16:00 CET schedule created no run; later one-time and five-minute UTC probes also created none during the observation windows.

Verified:

• The repository is enabled, private, not archived and not a fork.
• The workflow files are on the default branch, main.
• Actions and the workflows are enabled, with all actions allowed.
• The account associated with cron changes is active and linked to the commits.
• We changed cron using normal Git pushes to main without skip annotations.
• We explicitly disabled/re-enabled the workflows.
• GitHub's public status page showed Actions operational.

A fresh minimal workflow was also registered by a normal push at 16:12 UTC. Its push run succeeded, but no schedule run appeared after the 16:15 and 16:20 UTC cycles. It had no secrets, checkout, external services, conditions or token permissions:

name: Cron diagnostic
on:
  workflow_dispatch:
  push:
    branches: [main]
  schedule:
    - cron: '*/5 * * * *'
permissions: {}
jobs:
  heartbeat:
    runs-on: ubuntu-latest
    timeout-minutes: 1
    steps:
      - run: date -u

Both UTC and IANA-timezone schedules were tried in separate probes. We understand that cron can be delayed or dropped under load, and are not treating successful manual or push runs as proof that scheduling works. Temporary probes were disabled after the checks to avoid leaving recurring jobs behind.

The selected personal account's Support portal says "Technical support not included" and does not offer an Actions technical-support category. Is there a supported way to inspect or reset a repository's schedule registrations, or a private escalation route for a suspected event-creation failure? We would like to retain native GitHub scheduling.

An extended observation followed: the secret-free five-minute UTC diagnostic stayed enabled from 16:42 to 17:46 UTC (64 minutes). Its workflow-specific runs API still returned zero schedule runs at the end. We then disabled the diagnostic. This demonstrates non-triggering during that window, but does not establish the underlying cause.