GUIDE · GITHUB ACTIONS SCHEDULED · FREE

Monitor scheduled GitHub Actions — catch the silent 60-day disable

GitHub silently disables schedule: workflows after 60 days of repository inactivity — no email, no UI warning. One signed workflow_run webhook catches that, plus failed and hung scheduled runs, with zero YAML changes. Free for individuals, no monitor cap.

Start monitoring — free General GitHub Actions guide
This page is specifically about schedule: triggers. For general GitHub Actions monitoring (all triggers, webhook setup, failure log detail), see the GitHub Actions monitoring guide. This page focuses on the unique problems of the cron / scheduled workflow pattern.

The three ways your scheduled workflow disappears.

A workflow with a schedule: trigger is fundamentally different from a push-triggered workflow. It runs on a cadence, by itself, and its failures alert almost nobody.

The 60-day disable

GitHub silently stops it

After 60 days with no commits, pull requests, releases, or other activity in the repository, GitHub automatically disables all schedule: workflows. No email. No UI badge. The Actions tab still shows the workflow; it simply doesn't fire.

The wrong-person email

Alert goes nowhere useful

When a scheduled run fails, GitHub emails only the person who last committed to the workflow file's cron expression. That's often whoever set it up years ago — someone who left, whose email filter buries it, or who is on vacation when it matters.

The hung run

Starts, never finishes

A scheduled run that starts and never completes — stuck step, hung network call, infinite retry — is not a failure yet, so no failure email fires. GitHub's job timeout will eventually kill it, but by then you've missed the window where it mattered.

Setup: one webhook, about two minutes

The same webhook approach as the general GitHub Actions guide — but the key detail for scheduled workflows is the expected schedule window you configure in LastPing, which is what catches the 60-day disable.

Create a CI check in LastPing with your cron schedule

In the console, create a check, choose Monitor a CI/CD pipeline, and select GitHub. Set the expected schedule to match your workflow's schedule: cron expression — e.g. daily at midnight — plus a grace window (e.g. 30 minutes). This is the window after which a missing run signal opens an incident. Copy the webhook URL and one-time secret.

https://ping.lastping.dev/ci/github/<check-id>

Register the webhook in your repository

On GitHub: Settings → Webhooks → Add webhook.

  • Payload URL — the webhook URL from step 1
  • Content type — application/json
  • Secret — the one-time secret from step 1
  • Events — "Let me select individual events" → tick Workflow runs

Optionally, configure the check to filter to the specific workflow name and branch so only your nightly/scheduled workflow counts against the expected cadence.

Optional: attach failure log to the incident

Add an if: failure() step to your scheduled workflow that POSTs up to 64 KB of context to the detail endpoint. The failure reason is stored on the open incident — so the alert shows where it broke, not just that it broke.

# optional last step — scheduled workflow - name: Report failure detail to LastPing if: failure() run: | curl -fsS -X POST -H "Content-Type: text/plain" \ --data "${{ github.workflow }} / ${{ github.job }} failed on ${{ github.ref_name }} — run ${{ github.run_id }}" \ "https://ping.lastping.dev/ci/${{ secrets.LASTPING_CHECK_ID }}/detail"

What this specifically catches for scheduled workflows

The webhook covers the failures that GitHub's built-in notifications miss.

  • The 60-day silent disable — no workflow_run event arrives in the expected window; the schedule window deadline passes → incident opens. This is the case GitHub never notifies you about.
  • Failed scheduled runs — workflow_run arrives with conclusion: failure; incident opens with link to the run and failure detail if you added the optional step.
  • Hung scheduled runs — a run that starts but never completes within the completion window; the overrun opens an incident before GitHub's job timeout fires.
  • Alert to the right people — LastPing alerts your configured destinations (Telegram, Slack, Discord, email, webhook), not just the last cron committer.
  • Recovery — the next successful run closes the incident automatically. No manual reset.

For all GitHub Actions workflows (not just scheduled), see the general GitHub Actions monitoring guide. For cron jobs, Kubernetes jobs, and systemd timers, see the monitoring guides index. AI agents that run on a schedule can also self-register their own monitors via MCP.

Questions people ask

Front-loaded answers — the most important fact first.

  • Why did my GitHub Actions scheduled workflow stop running?

    GitHub automatically disables schedule: workflows after 60 days without any commits, pull requests, or other repository activity. The disable is silent — no email, no UI badge. The workflow YAML is still there; the trigger simply stops firing. A dead-man's-switch monitor that expects a run signal at your cron cadence catches this as a missing signal.

  • Does GitHub warn you before disabling a scheduled workflow?

    No. There is no prior warning, no 50-day email, no UI indicator that a workflow is approaching the 60-day limit. The workflow simply stops firing when the limit is reached. The only signal is the absence of runs — which requires an external monitor to detect.

  • Why does this need a schedule window, not just a webhook?

    A webhook fires when a run happens. If the run never happens — 60-day disable, network issue at GitHub's side, cron drift — no webhook fires. The expected schedule window in LastPing is the key mechanism: if the run signal doesn't arrive within [cron period + grace], an incident opens regardless of whether the webhook ever fired.

  • How do I re-enable a 60-day disabled workflow?

    Make any commit to the repository (even a no-op commit or a documentation edit), then go to Actions → your workflow → Enable workflow in the GitHub UI. GitHub re-enables the schedule immediately after activity. With a LastPing monitor, you find out it's disabled before it's been silent for days.

  • Is this free?

    Yes. CI/CD monitoring is a first-class free feature in LastPing — no monitor cap. See the general GitHub Actions guide for setup details, or compare free cron monitoring tools.

FREE FOR INDIVIDUALS · FULLY HOSTED

Your nightly backup is one quiet repo away from disappearing.

One webhook now beats finding out 60 days later. First alert wired up in about two minutes — and LastPing monitors itself the same way.

Start monitoring — free Full setup guide