One of our "daily" GTM workflows was silently skipped 11 times in 30 days.
I moved almost all our GTM automations off Trigger.dev and n8n. They now run on GitHub Actions.
GitHub Actions is a great home for scheduled workflows. Free compute, lives next to the code, secrets and logs built in.
Account scoring refresh, engagement intent reports, BDR performance tracking, outreach gap detection, intel & reply extraction. All daily crons, all running fine.
Except for one thing nobody warns you about: GitHub Actions crons never run on time.
I pulled 30 days of run history across all our workflows yesterday:
- Median start delay per workflow: 47 minutes to 3 hours after the scheduled time
- Worst case: 4+ hours late
- Another had a daily schedule for 6 weeks and ran twice. GitHub auto-disables schedules after 60 days of repo inactivity, and nothing tells you.
Every job posted to Slack, so I was basically reading a Slack channel like a newspaper and hoping I noticed what was missing.
With double-digit automations, that breaks fast. I needed one place to answer a simple question: "did everything run today?"
So as soon as Fable 5 launched, I prompted Claude to build a monitor (one Claude Code session, now live on Railway):
1. A single dashboard that pulls every cron across 7 repos plus our remaining Trigger.dev jobs and shows the day as a timeline: upcoming, ran, failed, never started
2. One-click re-run for failures, one-click dispatch for missed runs
3. A "copy context" button that grabs failure logs + metadata, so I paste straight into Claude Code and start debugging with full context
4. An n8n watchdog that checks every 15 minutes and auto-dispatches anything GitHub dropped, then posts to Slack that it did
The watchdog caught and rescued a real missed run on its very first tick.
Slack is back to being an alert channel instead of a monitoring system.
If you run scheduled jobs on GitHub Actions, compare your actual run times against your cron expressions. You're probably missing more than you think.