GitHub Actions vs Zapier Cron: When a Repo Is a Better Scheduler Than a Zap

Zapier’s Schedule trigger looks like cron for people who do not want cron. GitHub Actions on: schedule looks like cron for people who already live in a repo. I have used both to hit a URL every weekday morning. One of them left a trail I could diff. The other left a task history I could not put in git. That difference is the article.

This is not “never use Zapier.” It is when the job is already a script, a curl, or a small Node file, and you are paying Zapier to be an alarm clock. If the work never leaves Google Workspace, Apps Script versus Zapier is the cheaper clock. Alarm clocks should not have Formatter steps.

What each scheduler actually guarantees

Neither guarantees the minute. GitHub documents that scheduled workflows can be delayed, skipped during load, and generally treated as best-effort. Zapier documents delays and queues in its own language. If your job is “must run at 09:00:00 or the market is wrong,” you wanted a real worker and a queue, not a marketing cron. If your job is “weekday morning is fine, plus I will notice if Tuesday is missing,” both can work.

DST is the shared landmine. A Zap set to 9 a.m. in a timezone can do the right local thing. A cron in UTC will not spring forward with your brain unless you designed it. Actions schedules are UTC cron. I write that in the README because I will forget in November. Zapier hid the timezone in a UI I did not reopen for a year. I have had a “9 a.m.” Zap fire at 8 after a policy change I clicked through. The UI is not documentation. A YAML file is closer.

The repo as an operations manual

A scheduled Action lives next to the script it runs. Secrets live in the repo settings, which is imperfect and still better than a Zapier field I will export as JSON and lose. A pull request can change the hour. I can blame a commit. I cannot blame a Zapier version that does not exist.

Logs are CI logs. They are ugly and they are searchable. Zapier run history is prettier and worse at “what did we send.” When the webhook payload is wrong, I want the HTTP body in a log I can grep. I do not want a mapped field that says (text).

Minutes and billing are the other honesty. Actions has a free budget that is easy to blow with a matrix you did not need. A five-minute weekday curl is noise. A job that installs a universe of npm packages every morning is a hobby tax. Keep the scheduled job thin: checkout, run a small script, done. If the script needs a factory, you wanted a container that stays warm, not a cold start every dawn.

Zapier schedule as a product, not a crontab

The Zapier path wins when the next steps are Zapier apps. “Every Monday, create a Google Doc, ping Slack, add a row” is a Zap. Rebuilding that in Actions means you are writing a product. I will not do that for a team that only speaks Zapier.

The Zapier path loses when the middle is code. A Schedule plus a Code step plus a webhook is a GitHub Action wearing a meter. I have paid task counts to run JavaScript that a runner would have run for a rounding error. Pride said “keep it in one tool.” The bill disagreed.

Silent wait and delay steps are a different article on this site. I will only say: if your “cron” is a Delay inside a Zap that started yesterday, you do not have a scheduler. You have a nap. Naps miss Mondays. Actions will also miss Mondays under load, but it will not pretend a Delay is a clock.

Failure visibility

Actions can email the committer, fail a workflow, and sit red on a dashboard I already open. I still add an explicit ping to Healthchecks or a Pushcut URL because I do not open GitHub on weekends. A red badge I never see is a tree in a forest.

Zapier can email and can error-Zap. I have ignored those emails with the rest of the product mail. The win for Actions is not email. It is that the schedule and the script are one artifact I backup by existing in git. If GitHub is down, both tools are unhappy. If I am leaving Zapier, I export folklore. If I am leaving GitHub, I still have a clone.

Idempotency remains your job. A missed run plus a double run is how you send two invoices. The scheduler does not save you. A lock, a “already sent today” row, or a provider idempotency key saves you. I have double-sent from both platforms. I do not get to be smug.

Security and the public repo temptation

Scheduled Actions in a public repo are a billboard if you are sloppy with logs. Print fewer secrets. Use environments. Do not cron a script that dumps tokens. Zapier is private by default and still leaks when you share a Zap file. Different defaults, same human.

GitHub’s security theater can be useful: required reviews before someone changes the 5 a.m. production scrape. A Zapier folder is a shared login. For a solo, both are “you.” For a two-person shop, the PR is the reason I put the cron in the repo.

When I keep the Zap

Non-dev stakeholders will edit the time. The next action is a polished connector. The job is not worth a repo. I keep those Zaps and I do not migrate for ideology.

I also keep Zapier when the schedule is “when this calendar event starts,” which is not cron. People conflate calendar and cron because both involve mornings. They are different products. Actions will not read your personal calendar without you building a mess.

When I move to Actions

The job is curl, a Python file, or a small CLI I already own. I want history in git. I want to run the same job manually from the Actions tab. I want a README that states UTC. I want to stop paying per wake-up.

A private repo is enough. It does not need to be the company’s product repo. I keep a cron-jobs attic. One workflow per job. Names that say what will break if it dies. Cute names are how you ignore a failure.

Self-hosted runners are optional. I use GitHub-hosted for tiny HTTP. I use a home runner when the job must see the LAN. That home runner is a computer I must keep up. At that point I could have used cron on the same box. Actions is then the remote trigger UI and the log. That can still be worth it if I want the YAML in git and a button in the browser.

A migration that takes an evening

Pick one Zap that is Schedule plus webhook or Code. Write the script. Add a workflow with a cron, a manual workflow_dispatch, and a Healthchecks ping at the end. Run it by hand. Watch Tuesday. Then turn off the Zap. Do not migrate a 15-step Monday morning monster in the same evening. That Zap is a business process you forgot. Write it down first.

Keep a calendar note for the first DST boundary. Check both the new Action and any leftover Zaps. I have migrated the script and left a Zap “just in case.” Just in case is how you double-fire. Delete the Zap when the Action has a green week.

Concurrency, overlap, and the long job

A Zap that is still running when the next schedule fires can pile up or skip, depending on the product season. Actions can overlap workflows unless you set concurrency groups. I set them. A scrape that takes 40 minutes on a 15-minute cron is how you DDoS yourself. If the job is long, it is not a cron toy. It is a worker with a lock.

I also cap retries. Infinite retry on a payment endpoint is a horror movie. One retry plus a page is enough. Both platforms will retry more helpfully than you want if you click the defaults. Read the default. The default is how Monday becomes three Mondays.

The choice I would make again

A repo is a better scheduler than a Zap when the work is already software. Zapier is a better scheduler when the work is already Zapier. I stopped using Zaps as crontab for curl. I still use Zaps as glue. GitHub will delay my 9 a.m. job and I will live with it because I can read the file that defines 9 a.m. I could not read the Zap without opening a website that wanted to sell me Tables. That is not a moral victory. It is a maintenance victory, which is the only kind of victory a weekday morning job deserves. Put the hour in git. Put the ping in Healthchecks. Then go make coffee.