GitHub Actions schedule or a Sume schedule for a weekly video run?

For a weekly video run, GitHub Actions cron is UTC-first and best-effort at busy times; a Sume schedule has a timezone and a spend cap. You can also chain them.

5 min readSume
All posts

Use a Sume schedule when the clock alone should start a video run and you want a timezone and a per-run spend cap in the schedule itself. Use a GitHub Actions schedule when the run belongs in a repo workflow with other steps, and call Sume from it. The two combine: a Sume schedule can be started by POST /v1/actions/{action_id}/runs from a workflow.

What GitHub says about its schedule

GitHub's documentation for the schedule event says it uses POSIX cron syntax, that the shortest interval is every 5 minutes, and that times are in UTC by default, with an optional IANA timezone. It also warns that scheduled runs can be delayed at the start of the hour when load is high, and that scheduled workflows in public repositories are disabled after 60 days without repository activity.

What a Sume schedule is

A Sume schedule is a saved Agents automation with instructions, a model, a 5-field cron expression with an IANA timezone, and a spend cap. When it fires, Sume runs it as an Agent in a fresh thread and returns a structured run receipt. You create schedules in the dashboard, or ask the agent in chat to make one, and the API can list, read, start and monitor runs but cannot create or edit schedules.

Schedule features side by side (GitHub docs read 2026-10-05, Sume docs from repo)
FeatureGitHub Actions scheduleSume schedule
Cron syntaxPOSIX, 5 minute minimum5-field cron
TimezoneUTC default, optional IANAIANA timezone on the schedule
Busy-time behaviorCan be delayed at the start of the hourNot described in the docs
InactivityPublic-repo schedules disabled after 60 days idleStatus active or inactive
Spend limitNone, you add your ownSpend cap per run, default $1.00
Overlapconcurrency groups in the workflowon_active_run skip or reject, default skip

Start a Sume schedule from GitHub

The workflow below runs weekly, calls a Sume schedule whose API trigger is enabled, and uses the GitHub run id as the idempotency key, so a re-run of the workflow does not start a second video run. Set SUME_API_KEY as a secret and SUME_ACTION_ID as a variable. The key needs actions:read and actions:write.

name: weekly-video
on:
  schedule:
    - cron: "17 6 * * 1"
  workflow_dispatch:
jobs:
  start:
    runs-on: ubuntu-latest
    steps:
      - name: Start the Sume run
        env:
          SUME_API_KEY: ${{ secrets.SUME_API_KEY }}
          ACTION_ID: ${{ vars.SUME_ACTION_ID }}
          KEY: gh-${{ github.run_id }}
        run: |
          test -n "$SUME_API_KEY" -a -n "$ACTION_ID"
          curl -sS --fail-with-body -X POST \
            "https://api.sume.com/v1/actions/$ACTION_ID/runs" \
            -H "Authorization: Bearer $SUME_API_KEY" \
            -H "Content-Type: application/json" \
            -H "Idempotency-Key: $KEY" \
            -d '{}'

Choosing where the clock lives

The minute is 17, not 0, on purpose, because GitHub documents delays at the start of the hour. If the Sume schedule already has a cron, calling the run endpoint adds a second trigger and the schedule keeps its own cadence. If you want only the workflow to start it, make the schedule API-triggered. The docs say a trigger type cannot be changed after creation, so decide before you create it.

One clock per job

Pick one clock per job. Two clocks for one weekly video give you two videos, and the on_active_run default of skip will only hide the second one if it starts while the first is still running.

Sources

Related posts

More in Comparisons

All Comparisons posts

Written by Sume