Cron Doctor · configuration analysis

GitHub Actions cron validator

Check your GitHub Actions schedule before relying on it. Paste workflow YAML to review cron triggers, timezone context, concurrency, and timeout settings—without running the workflow.

No signup needed for the checker. Running production jobs? Pro covers up to 50 jobs for $9.99/month, for one owner.

Open Cron Doctor

What you can check

  • Explain supported on.schedule cron triggers and preview nominal run times.
  • Read each trigger’s timezone and visible workflow or job concurrency settings.
  • Inspect static timeout-minutes values and evidence for schedule risks.

What remains unknown

This is not full workflow validation: it does not resolve secrets, execute steps, or inspect your repository. Valid schedule syntax does not prove dispatch, completion, or correct output. Runtime expressions and unsupported syntax can limit analysis.

Synthetic example

A deliberately minimal example to try in the checker. It has no explicit timeout or concurrency group and runs at the start of the hour. The echo command is synthetic; this is not a production backup workflow.

name: backup
on:
  schedule:
    - cron: '0 2 * * *'
jobs:
  backup:
    runs-on: ubuntu-latest
    steps:
      - run: echo ok

Your configuration is sent to PingCron for analysis. It is not saved and is never executed. A static report does not establish runtime health.

Official scheduler reference · Explore ongoing monitoring

Valid cron, but GitHub Actions is not running?

Start with the report, then inspect the repository and Actions run history. A static checker cannot see whether your deployed workflow is enabled, dispatched, or successful.

  • Syntax and timezone: use five cron fields with an interval of at least five minutes. GitHub defaults to UTC and supports an explicit IANA timezone on a schedule trigger. Check each trigger’s timezone; a preview is a nominal time, not a dispatch guarantee.
  • Default branch and inactivity: the workflow must exist on the default branch. Public repositories can have scheduled workflows disabled after 60 days without repository activity.
  • Runner delays: GitHub documents delays and possible dropped runs under heavy load, especially near the start of an hour. An off-hour minute can reduce congestion risk; it does not guarantee a run.
  • Timeouts and overlap: inspect timeout-minutes and concurrency in the report. Choose limits for your workload; cancellation can interrupt useful work. A configured group alone does not prove the workflow is safe.

References: GitHub schedule behavior · GitHub concurrency controls.

Keep GitHub Actions. Monitor 21–50 jobs for $9.99/month.

The checker reviews configuration once. PingCron monitoring expects completion check-ins and alerts when a signal is missing beyond its grace period—even if no workflow run exists to send a failure notification. It does not dispatch workflows, retry jobs, or identify why a check-in is missing.

Pro covers up to 50 monitors for one owner across GitHub Actions, cron, and other scheduled workloads, with email, Slack, Discord, and webhook alerts. Count independently monitored workloads, not every YAML job or step.

For 30 monitored jobs and one user, monthly list prices are PingCron Pro $9.99, Healthchecks Business $20, and Cronitor Business $65. Healthchecks offers 20 free checks and shared projects; Cronitor Business includes 12-month retention and SMS/on-call features. PingCron’s price advantage is for an owner who needs this monitoring scope, not feature parity.

USD monthly rates checked October 17, 2026; taxes, discounts, and add-ons excluded. Sources and tradeoffs: Healthchecks comparison · Cronitor comparison.

Pro retains 30 days of data for daily reported-outcome summaries; the individual list shows the latest 100 receipts. This is not a searchable archive of application logs. Shared account access starts on Team.

Monitor one workflow freeChoose Pro — $9.99/month

Free: 5 monitors, 7-day history, no credit card. Pro: create your account, then continue to checkout.

Prove one scheduled workflow is covered

  1. Create a monitor manually for one expected workload. Match its schedule and timezone. Include normal runner delay and workload duration in the grace period; detection and alert delivery add further delay.
  2. Store the monitor’s check-in URL as a GitHub Actions secret. Report success only after all required work and output checks succeed. Restrict that signal to the intended scheduled workload: manual runs must not satisfy its monitoring expectation. Multiple schedules or independent jobs may need separate monitors so one cannot hide another’s absence.
  3. Keep failure, cancellation, and skipped work from sending a success signal. Do not use an unconditional success heartbeat. Inspect the real output and confirm the check-in from an automatic scheduled run.
  4. Verify your alert destination, then test a missed check-in and recovery on an isolated monitor. Add the rest of your workloads after this first path works.