- GitHub Actions runs a scheduled workflow (via
cronin a.ymlfile) that calls the Anthropic API, writes an article, and pushes it to WordPress as a draft — no server, no n8n instance, no always-on process. - Free-tier GitHub Actions gives 2,000 build minutes per month on private repos (unlimited on public repos), which comfortably covers a daily content job that runs in under 2 minutes.
- Credentials live in GitHub Actions Secrets (repo Settings → Secrets and variables), never in the workflow YAML or committed code — this is the single most common setup mistake teams make.
- The failure mode unique to this approach: a workflow can fail silently unless you add a Slack or email notification step on failure — GitHub does not alert you by default beyond a red X on the commit.
Most AI content pipelines get built on n8n or Make.com because they have visual editors. That is the right call for a marketing team without an engineer.
For a team that already lives in GitHub — committing code, reviewing pull requests, running CI — GitHub Actions is a legitimate, often simpler alternative. The pipeline lives in the same repo as the site, versioned in Git, with no separate service to pay for or keep online.
This guide covers the exact workflow file structure, the secrets setup, and the four failure modes that catch teams building this for the first time.
Why Would You Run a Content Pipeline on GitHub Actions Instead of a Dedicated Automation Tool?
GitHub Actions wins when the team already has a GitHub-based deploy process — the content workflow becomes another job in a repo that already has CI running, reviewable in the same pull request history as everything else.
It also wins on cost for low-volume, scheduled jobs. A workflow that runs once a day for 90 seconds uses roughly 45 minutes of the monthly 2,000-minute free allowance — well within free tier even on a private repo, with no separate hosting bill the way a self-hosted n8n VPS requires.
n8n still wins for teams that need a visual debugging view, non-engineers editing the pipeline, or complex branching logic. GitHub Actions workflows are YAML — readable, but not something a marketer edits comfortably.
scripts/generate_and_push.py), not inline in the workflow YAML. This makes the pipeline runnable and testable locally with python scripts/generate_and_push.py before you ever trigger it via GitHub Actions — catching bugs without burning Actions minutes.
What Does the GitHub Actions Workflow File Actually Look Like?
The workflow lives at .github/workflows/daily-content.yml. It defines a schedule trigger, a runner, and the steps that check out the repo, install dependencies, and run the generation script.
| Step | Action | Purpose |
|---|---|---|
| 1 | on: schedule: cron | Triggers the workflow daily at a fixed UTC time |
| 2 | actions/checkout@v4 | Pulls the repo so the script has access to templates/entity data |
| 3 | actions/setup-python@v5 | Installs the Python version the script needs |
| 4 | pip install -r requirements.txt | Installs the Anthropic SDK and WordPress REST client libs |
| 5 | python scripts/generate_and_push.py | Runs the generation + WordPress push, reading secrets as env vars |
The cron schedule field uses standard five-field cron syntax, but always in UTC — a common mistake is setting a schedule expecting local time and getting a post generated eight hours off from intended.
How Do You Store the Anthropic API Key and WordPress Password Securely?
GitHub Actions Secrets, set under repo Settings → Secrets and variables → Actions, are encrypted at rest and only decrypted inside the running workflow. They are never printed in logs — GitHub automatically masks any value matching a stored secret.
Reference them in the workflow YAML as ${{ secrets.ANTHROPIC_API_KEY }} and pass them to the script as environment variables under the env: key of the step. The Python script then reads them with os.environ["ANTHROPIC_API_KEY"] — the same pattern as any local .env file, just sourced differently.
Never hardcode a key in the YAML file itself, even temporarily for testing. GitHub Actions workflow files are committed to Git history, and a key committed once remains recoverable from that history even after a later commit removes it.
pull_request from a fork does not have access to repo secrets by default, as a GitHub security measure against secret exfiltration via a malicious PR. If your pipeline needs to run on pull requests (for a staging preview), use pull_request_target with careful review gating instead — never simply grant fork PRs secret access to work around the error.
How Do You Push the Generated Article to WordPress From Inside the Workflow?
The final step of the Python script calls the WordPress REST API’s POST /wp-json/wp/v2/posts endpoint, authenticated with a WordPress Application Password (not the account login password) passed via Basic auth.
The request body sets status: "draft" explicitly — never omit this field, because the WordPress REST API defaults new posts to draft only when the authenticated user’s role permits publishing but the field is unset, which is inconsistent across WordPress versions and not something to rely on.
A successful response returns the new post’s ID and edit link in JSON. The workflow script should log that ID as a GitHub Actions “step summary” so it is visible directly in the Actions run page without needing to check WordPress separately.
$GITHUB_STEP_SUMMARY (a special environment variable GitHub Actions provides) at the end of the script: echo "Created draft: {title} (ID {id})" >> $GITHUB_STEP_SUMMARY. This renders as formatted markdown directly on the workflow run summary page — no need to open WordPress admin to confirm the job worked.What Happens When the Workflow Fails Halfway Through — Does It Leave a Half-Published Draft?
It depends entirely on how the script is structured. If article generation happens first and the WordPress push happens last, a failure during generation (an API timeout, a malformed response) simply exits before any WordPress call — nothing gets pushed, which is the safe default.
A failure during the WordPress push itself is the riskier case: a partial network failure can leave a post created with incomplete content if the script does not verify the full response. Wrap the push call in a check that confirms the response contains both an ID and the expected content length before treating the job as successful.
GitHub Actions does not roll back or clean up side effects automatically. A workflow that creates a broken WordPress draft and then fails will leave that broken draft sitting in the admin queue until a human notices it.
“Secrets are encrypted environment variables that you create in an organization, repository, or repository environment. GitHub Actions can only read a secret if you explicitly include the secret in a workflow.”
— Per GitHub’s official Actions documentation on encrypted secrets (GitHub, 2025)
How Do You Get Notified If the Daily Job Fails Instead of Discovering It a Week Later?
Add a final step in the workflow with if: failure() — this step only runs when a prior step in the job has failed, regardless of what the failure was.
That step can call a Slack incoming webhook, or simply send an email via a GitHub Action like dawidd6/action-send-mail, passing the failed step’s log output as the message body. Without this, the only native signal is a red X on the commit history that nobody is watching daily.
Teams running this in production should treat the failure notification step as mandatory, not optional — a silent content pipeline failure is functionally the same as forgetting to publish for a week, and it is invisible until someone checks the site’s post count.
| Setup | GitHub Actions | Self-hosted n8n |
|---|---|---|
| Hosting cost | Free (within 2,000 min/mo private repo tier) | VPS running cost, always-on |
| Version control of pipeline logic | Native (it’s a Git repo) | Manual export/import of workflow JSON |
| Editable by non-engineers | No (YAML + Python) | Yes (visual node editor) |
| Failure alerting | Manual setup (if: failure() step) | Built-in error workflow trigger |
GitHub Actions is a legitimate, free-tier-friendly way to run a daily AI content pipeline for a team already working in Git — no separate automation server to host or pay for. The setup that matters most: keep the Anthropic API key and WordPress Application Password in GitHub Actions Secrets (never in the YAML), always set status: "draft" explicitly on the WordPress push, and add an if: failure() notification step from day one. Without that last step, a broken pipeline fails silently until someone notices the site stopped publishing.
Frequently Asked Questions
Does GitHub Actions charge extra for calling an external API like Anthropic’s from inside a workflow?
No. GitHub Actions bills only for the compute minutes the workflow runner uses, not for outbound API calls the script makes. The Anthropic API cost is separate, billed directly by Anthropic based on tokens used.
Can a GitHub Actions workflow run more than once a day for higher content volume?
Yes. The cron schedule field accepts multiple trigger times, and GitHub Actions has no hard limit on job frequency beyond the monthly minutes allowance. A team publishing three articles a day would still use well under 5% of the free-tier minutes.
What happens if two scheduled runs overlap because the previous run took longer than expected?
By default, GitHub Actions allows concurrent runs of the same workflow, which can cause duplicate posts if both runs pick the same topic queue entry. Add a concurrency: block to the workflow YAML with a fixed group name to force sequential execution and cancel or queue overlapping runs.
Is it possible to trigger the workflow manually for testing without waiting for the scheduled time?
Yes, by adding workflow_dispatch: alongside the schedule: trigger in the YAML. This adds a “Run workflow” button in the GitHub Actions tab, letting you trigger the exact same job on demand for testing.
Do private repository Actions minutes reset monthly or accumulate?
They reset at the start of each billing cycle and do not roll over. Unused minutes from one month do not carry into the next.
Last updated: 2026-08-18. Technical specifications based on GitHub Actions documentation, GitHub’s Encrypted Secrets documentation, and the WordPress REST API Handbook as of August 2026.
English 
한국어 