Schedule Observability & Assurance Capabilities
Schedule Assurance
A scheduled run that never starts does not fail, so failure alerts never see it. Assurance compares every expected cron slot from the last 7 days with the runs that actually started and flags did-not-start, late, did-not-finish, and disabled workflows.
Unified Schedule Calendar
Every on.schedule.cron across all repositories and branches in one calendar and list view — plain-English schedules in UTC, run times in your local timezone, and the next ten runs per workflow.
Busiest Hours & Contention
A weekday-by-hour grid shows when scheduled runs bunch up. When ten or more runs fire in the same hour they queue for runners together — spread them out before queue times inflate.
Missed-Schedule Alerts
Route did-not-start, late, stuck, and disabled detections to Slack channels or email recipients with per-rule repository and category filters — plus cooldowns so frequent crons batch into one digest.
See It In Action
Explore schedules and assurance live with real data.
Open the interactive demo to browse the schedule calendar, check per-workflow assurance statuses, and review the recent alerts feed — no sign-up required.
View Live DemoHow Schedule Assurance Works
No workflow changes required — Gitera compares the cron slots that should have run with the runs GitHub actually started.
Parse Every Cron Trigger
Gitera reads on.schedule.cron entries from workflow files across all repositories and branches, in each schedule’s own timezone, and projects every expected run slot.
Match Slots To Real Runs
Every 30 minutes, expected slots are compared with ingested schedule-triggered runs. A 10-minute ingestion buffer prevents false alarms while run data is still arriving.
Score Each Workflow
Per-workflow thresholds — a 30-minute grace period, a 120-minute missed-after cutoff, and an optional duration SLO — turn slots into statuses: on time, late, did not start, did not finish, or disabled.
Alert & Auto-Resolve
Missed-schedule rules notify Slack or email with links to the workflow and its last run. When a missing run finally arrives or a disabled workflow is re-enabled, the event resolves itself in the feed.
Key Benefits
The failures you never see are the ones that hurt most
Catch Silent Skips
GitHub drops scheduled runs under load and nobody gets notified — nightly builds, backups, and security scans that never ran surface immediately
Spread The Load
See contention before it costs you — move nightly jobs off top-of-hour crons and spread them across quieter slots with the busiest-hours heat map
Per-Workflow SLOs
Tune grace periods, missed-after cutoffs, and max-duration SLOs per workflow so a five-minute lint and a two-hour nightly build each get the right threshold
Cron schedule observability and assurance
GitHub buries on.schedule.cron entries inside individual workflow files. Gitera parses them across every repository and branch into one calendar and list view with local-time run projections, plain-English cron text, and a busiest-hours heat map that shows when scheduled jobs compete for runners.
Schedule Assurance compares each expected cron slot with the runs that actually started, so a run GitHub skipped under load shows up as did not start instead of silently passing. Per-workflow settings tune grace periods, missed-after cutoffs, and duration SLOs, and detected problems feed GitHub Actions alerts through missed-schedule Slack and email rules.
Use the assurance tab to spot forgotten schedules in legacy repositories that still burn compute tracked in cost analysis, and pair it with security policies such as no-top-of-hour-cron and fork guards to keep every schedule healthy.
Schedules FAQ
Why did my scheduled GitHub Actions workflow not run?
GitHub delays scheduled runs under load and sometimes drops them entirely, especially crons that fire on the hour. A skipped run does not fail, so success/failure alerts never see it. Gitera checks expected cron slots against ingested schedule-triggered runs every 30 minutes and records a did-not-start event when no run arrives by the missed-after cutoff, so the gap surfaces in schedule assurance instead of staying invisible.
How do I get alerted when a GitHub Actions cron job is missed?
Create a Missed schedules rule under Notifications: pick the repositories and workflow categories it applies to, choose Slack, email, or both, and set a cooldown so frequent crons batch into one digest. Alert emails link straight to the assurance tab of schedules.
Which timezone does GitHub Actions use for cron schedules?
GitHub evaluates cron expressions in UTC unless the schedule declares a timezone. Gitera evaluates slots in the schedule’s own timezone and renders every projected run in your local time, so the schedules calendar shows both the plain-English UTC schedule and the wall-clock time your team will see.
What counts as a late or stuck scheduled run?
Each workflow has a grace period (default 30 minutes) after which a started run counts as late, a missed-after cutoff (default 120 minutes) after which no run counts as did not start, and an optional max duration SLO that flags runs still going past their limit. Disabled workflows are reported too, since GitHub will never fire their schedule.
Related Gitera capabilities
Explore all features on the Gitera homepage or read insights on the blog.