When a scheduled GitHub Actions workflow does not run, check whether GitHub created a workflow run. A missing run and a failed job require different fixes. A notification step inside the workflow cannot report a run that never started.
Check the trigger before the job
Confirm that the workflow is enabled and that its scheduled definition exists on the default branch. Inspect the actual workflow file there, rather than a version on an unmerged branch. Then compare the expected trigger with the Actions run history.
GitHub documents that scheduled events can be delayed during high load, particularly around the beginning of an hour; sufficiently high load can cause queued jobs to be dropped. Scheduling away from the start of the hour can reduce exposure to that busy period, but it does not make execution punctual or guaranteed. See GitHub's workflow troubleshooting documentation.
Distinguish missing, queued, skipped, and failed
| Observation | Next investigation |
|---|---|
| No workflow run exists | Enabled state, default-branch definition, schedule, service status |
| Run exists but is queued | Runner availability and execution capacity |
| Run exists but work is skipped | Job conditions and the intended event context |
| Job starts and fails | Logs, permissions, configuration, dependencies |
| Job succeeds but the report is stale | Application-level output validation |
A manual run can help test job logic if the workflow supports it, but it does not prove that the scheduled trigger works. Record scheduled execution separately.
Monitor completion outside GitHub Actions
For a daily report, configure an external heartbeat monitor to expect a signal after the report passes validation. That expectation remains in place even when GitHub never creates the workflow run.
Send completion only after the required work and checks pass. If several jobs contribute to the output, define which final job represents successful completion and which dependencies must succeed. Do not send a success heartbeat from unconditional cleanup.
Use a separate failure signal when execution reaches an error-handling path. Missing-run detection remains necessary because no workflow step can execute when the workflow itself is absent.
Allow for normal delay without hiding outages
Choose a grace period appropriate to the business deadline and observed scheduling variation. If a report is needed before the team starts work, an alert after that deadline may be operationally useless even if the threshold looks generous.
Avoid using a very frequent monitor expectation for a daily workflow. Match the expectation to your schedule and document the timezone assumptions on both sides. If exact-time execution is a hard requirement, evaluate the scheduler against that requirement separately; monitoring detects a miss but does not repair scheduling guarantees.
Connect ActionBox after confirming availability
ActionBox Watches can represent a scheduled completion expectation and turn a missing signal into an Action. Confirm support for your hosted account in the Watch documentation. Store the returned heartbeat capability as a protected secret, never directly in the workflow file or build logs.
Follow the heartbeat integration guide for signaling and recovery. You configure the HTTP calls in your own workflow; this is not a dedicated native integration.
Test a missed run and recovery
Create a disposable workflow that performs harmless work. Verify a successful scheduled run, an explicit failure, and an omitted completion signal. Observe the resulting monitor state and recovery after restoring normal execution.
Do not disable a production workflow just to create a demonstration. Keep the test separate and remove its monitor when the test ends. If the scheduled work produces backups, add the output checks described in the backup monitoring guide.
Create a free Source to begin setup, then confirm Watch availability before relying on monitoring.