The Free Cron Scheduler Hiding in Every GitHub Repo You Own

Aaron — Thu, 18 Jun 2026 05:08:44 +0000

I used it to build a zero-cost "dead man's switch" that catches silent failures before I do.

Quick context before anything else: I packaged this exact recipe, plus six more like it, into a small cookbook — The GitHub Actions Cookbook ($10, instant download, PDF + ready-to-fork workflow files). Everything below is the full, real recipe from it, not a watered-down preview. If it's useful to you, the other six are built the same way.

Now, here's the thing almost nobody talks about.

You already have a free cron scheduler. You're just not using it.

If you've ever set up GitHub Actions, it was probably for one job: run the tests, build the thing, ship it on push. That's the entire relationship most developers have with it.

Buried in the same feature, though, is a schedule trigger. It runs on standard cron syntax. It costs nothing on a public repo, and a generous free allowance on a private one. It runs on infrastructure you never provision, patch, or get paged about at 3am. You already pay for none of it, and you already have it, in every repo you own.

I started actually using it after a small, annoying failure taught me a lesson the hard way.

The problem: things fail silently

I had a script — doesn't matter exactly what it did, the shape of the problem is the point — that was supposed to run on a schedule and quietly do its job. One day I needed it, and it hadn't run in over two weeks. No error. No email. No red X anywhere. It just stopped, and nothing in my world noticed.

That's the specific kind of failure that's worse than a crash: a crash is loud. Silence is invisible until the exact moment you need the thing that silently stopped happening.

The fix isn't complicated once you frame it correctly: you don't need to monitor the process itself, you need something else watching for its absence. That's the entire idea behind a "dead man's switch," and it turns out GitHub Actions is a genuinely good place to build one.

The recipe: a heartbeat, and something watching it

The shape is simple. Something — your script, your other system, even you manually — touches a file in a repo on a schedule, proving it's alive. A separate, scheduled GitHub Actions job checks how long it's been since that file last changed. If it's been too long, it sends you an alert. If not, it does nothing, which is exactly what you want 99% of the time.

Here's the complete workflow file:

name: Heartbeat Monitor
on:
  schedule:
    - cron: '0 9 * * *'   # daily at 9am UTC
  workflow_dispatch:

jobs:
  check-heartbeat:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # full history — required, see below

      - name: Check last heartbeat
        run: |
          LAST=$(git log -1 --format=%ct -- heartbeat.txt)
          NOW=$(date +%s)
          HOURS=$(( (NOW - LAST) / 3600 ))
          echo "Hours since last heartbeat: $HOURS"
          if [ "$HOURS" -gt 24 ]; then
            echo "STALE=true" >> $GITHUB_ENV
          fi

      - name: Alert if stale
        if: env.STALE == 'true'
        run: |
          curl -X POST -H 'Content-Type: application/json' \
            -d '{"content": "No heartbeat in 24+ hours."}' \
            "${{ secrets.DISCORD_WEBHOOK_URL }}"

Walking through what's actually happening: the job runs once a day and pulls the repo's full git history (that fetch-depth: 0 matters, more on that in a second). It looks at when heartbeat.txt was last touched, using git log rather than the filesystem's modified time, because git history survives a fresh checkout and a file's mtime doesn't. It does the arithmetic in plain bash, sets an environment flag if too much time has passed, and only fires the alert step if that flag is set. No alert fires on a normal day — the workflow just runs, finds nothing wrong, and exits quietly.

Setting it up, start to finish

Create an empty heartbeat.txt at the root of your repo and commit it once.
Whatever process you're actually monitoring needs to update and commit that file on its own schedule — a single line with a timestamp is enough.
Add a DISCORD_WEBHOOK_URL repository secret (Settings → Secrets and variables → Actions → New repository secret), pointed at a Discord channel webhook. Slack's incoming-webhook format works too, with a small tweak to the payload shape.
Adjust the 24 in the threshold check to match how often your process is actually supposed to run.

That's the whole setup. Ten minutes, generously.

The one thing that will bite you

fetch-depth: 0 is not a throwaway line — it's the part of this recipe that breaks silently if you skip it. GitHub's default checkout only pulls the most recent commit, not the full history. Without the full history, git log -1 --format=%ct -- heartbeat.txt either returns nothing or returns the wrong timestamp, and your dead man's switch quietly stops doing the one thing it exists to do — catching silence. It fails exactly the way the thing it's supposed to monitor failed, which is a little too on-the-nose for my taste.

Where this goes from here

Once this pattern clicks, it generalizes fast: schedule trigger, a step that checks or fetches something, a conditional step that reacts. Swap the middle step and you get a different tool entirely. I've used the same shape to build a free uptime watchdog for a side project's API, an automatic cleaner for issues nobody ever closes, and a script that quietly turns a changing metric into a personal dataset by committing one line to a CSV every day — no database, no server, just git.

Those three, plus three more, are written up the same way — full code, real setup steps, the specific gotcha that catches people — in The GitHub Actions Cookbook. Seven recipes, a PDF walkthrough, and all seven workflows as standalone files you can drop straight into .github/workflows/. Ten dollars, and if you've got a GitHub account, you already have everything else you need.

What's the most useful thing you've automated with GitHub Actions that has nothing to do with CI? Curious what other "free cron job" tricks people are running.