GitHub Actions + Sandglass: Monitor Scheduled Workflows

Q: Does this work with GitHub Actions matrix builds?

Yes. The recommended pattern is to add a final job with "needs: [your-matrix-job]" and put the heartbeat curl there. That job only runs when all matrix legs pass, so one heartbeat ping confirms the full matrix.

Q: What happens if GitHub skips a scheduled run due to inactivity?

GitHub can skip scheduled workflows on inactive repositories. Sandglass treats a missing heartbeat the same regardless of cause: if the ping does not arrive within the configured window, an incident opens. This is exactly the failure mode you want to catch.

Q: Can I monitor multiple scheduled workflows with one Sandglass account?

Yes. Create a separate heartbeat check for each workflow. Each gets its own URL, its own interval, and its own incident history. You can group related checks under the same Sandglass group to share alert channels.

Q: Is the heartbeat URL sensitive? Should I treat it like a secret?

Treat it like a low-sensitivity secret. Anyone with the URL can ping your heartbeat, which would suppress false-positive incidents. Storing it as a GitHub Actions secret (not a plain env var) keeps it out of logs and is the right default.

Q: What interval should I set on the Sandglass heartbeat check?

Set it to match your cron schedule plus a small buffer. For an hourly workflow, 65 or 70 minutes is a reasonable window. Too tight and transient GitHub queue delays trigger false positives; too loose and you wait longer before an incident opens.

Scheduled workflows that go quiet are the hardest failures to catch. Sandglass catches them.

Add a heartbeat ping to any GitHub Actions scheduled workflow so Sandglass knows it ran. If the workflow silently stops firing, Sandglass opens an incident before your users notice.

Requirements

A GitHub repository with at least one scheduled workflow (cron trigger)
Permission to add repository secrets
A Sandglass heartbeat check with its URL stored as the SANDGLASS_HEARTBEAT_URL repository secret
A Sandglass account on any plan (heartbeat checks are available on the free tier)

How to connect

Step 1: Create a heartbeat check in Sandglass

In Sandglass, add a new Heartbeat check. Set the expected interval to match your workflow schedule — for example, 60 minutes for an hourly cron. Copy the heartbeat URL shown after saving.

Tip

Name the check after the workflow (e.g., "nightly-report sync") so incidents are immediately identifiable in the Sandglass dashboard.

Step 2: Store the heartbeat URL as a repository secret

In your GitHub repository, go to Settings > Secrets and variables > Actions and create a new secret named SANDGLASS_HEARTBEAT_URL. Paste the heartbeat URL as the value. Secrets are encrypted and never appear in logs.

Step 3: Add the heartbeat step to your workflow

At the end of your job steps, add a step that runs: "curl -fsS -m 10 --retry 3 \"${{ secrets.SANDGLASS_HEARTBEAT_URL }}\"". Because it comes last, it only fires when all preceding steps succeed. A failed earlier step skips it, and Sandglass opens an incident when the heartbeat goes missing.

Tip

If you want to report failures explicitly rather than waiting for a missed heartbeat, add a second step under "if: failure()" that curls the /fail variant of the URL.

Step 4: Verify the first run

Trigger the workflow manually via "Run workflow" or wait for the next scheduled run. In Sandglass, the heartbeat check should flip to "Up" within seconds of the curl completing. If it stays pending, check the Actions run log to confirm the curl step executed and returned 200.

What you can do

Catch silently broken schedules: GitHub does not alert you when a scheduled workflow stops running. Sandglass does. If the cron fires but the job fails before the heartbeat step, or if GitHub skips the run entirely, Sandglass opens an incident.
Zero infrastructure overhead: The integration is a single curl command in your YAML. No external services, no tokens beyond the heartbeat URL, no webhook receivers to maintain. The heartbeat URL itself is the entire integration.
Works with matrix builds: For matrix workflows, ping the heartbeat from a final job that depends on all matrix legs using "needs: [build]". That way a single heartbeat confirms every matrix combination completed, not just one.
Explicit failure reporting: The /fail suffix on the heartbeat URL lets you open a Sandglass incident immediately on job failure rather than waiting for the heartbeat window to expire. Combine both: ping the normal URL on success, ping /fail on failure.

Frequently Asked Questions

Does this work with GitHub Actions matrix builds?

What happens if GitHub skips a scheduled run due to inactivity?

Can I monitor multiple scheduled workflows with one Sandglass account?

Is the heartbeat URL sensitive? Should I treat it like a secret?

What interval should I set on the Sandglass heartbeat check?

Know when your scheduled workflows go quiet

Start free

Free plan, no credit card required.