Cloudflare Pages' Git integration watches a single repository. Push to that repo and Pages rebuilds. That's the only trigger it understands natively.
If your project spans two repositories — a content repo and a frontend repo deployed on Pages — pushing to the content repo does nothing. Pages has no knowledge of it.
The solution is a Deploy Hook: a URL that Cloudflare generates for your Pages project. When you send a POST request to it, Pages queues a new build immediately, without any Git push. You call it from GitHub Actions in the other repository.
Why Git integration alone won't work
When you connect Cloudflare Pages to a GitHub or GitLab repository, it installs a webhook in that repository and monitors pushes to the branches you configure. No mechanism exists to monitor a second repository through this same integration.
If repository A holds your content and repository B holds your Pages frontend, a push to A simply isn't visible to Pages. The two are unconnected from Cloudflare's perspective.
This is exactly the setup we ran into: a content repository and a Pages frontend repository maintained separately. Every push to the content repo was invisible to Pages — no error, no missed-trigger notification. Pages simply never rebuilt. The Deploy Hook was the only way to bridge them.
Create a Deploy Hook in Cloudflare Pages
Open the Cloudflare dashboard and navigate to Workers & Pages → your project → Settings → Builds & deployments. Scroll down to the Deploy Hooks section and click Add Deploy Hook.
Give the hook a descriptive name — something that identifies what will trigger it, like content-repo-main. Select the branch you want Pages to build when the hook fires. Click Save and copy the generated URL.
The hook is branch-specific. A hook pointed at main triggers a production build. If you want separate hooks for different environments, create one per branch.
Treat this URL as a secret. Anyone who has it can trigger a build on your project.
Store the hook URL as a GitHub Secret
In the trigger repository (not the Pages repo), open Settings → Secrets and variables → Actions → New repository secret.
- Name:
CLOUDFLARE_DEPLOY_HOOK - Value: the URL you copied from Cloudflare
Never paste the URL directly into a workflow file. That would commit it to your repository history and expose it to anyone with read access. GitHub Actions masks secret values in logs automatically; a URL in plain text is not masked.
Add the workflow to the trigger repository
Create .github/workflows/deploy-pages.yml in the trigger repository:
name: Trigger Cloudflare Pages Deploy
on:
push:
branches:
- main
jobs:
trigger:
runs-on: ubuntu-latest
steps:
- name: Trigger Cloudflare Pages build
run: |
curl --silent --fail -X POST "${{ secrets.CLOUDFLARE_DEPLOY_HOOK }}"
The --fail flag makes curl return a non-zero exit code when Cloudflare responds with an HTTP error status. Without it, the step will appear to succeed even if the POST failed.
On every push to main in this repository, the workflow fires the POST request. Cloudflare queues a new Pages build for the branch the hook is configured for.
Restrict which pushes trigger a redeploy
Every push to main will trigger a build by default. If your trigger repository contains files that don't affect what Pages renders — configuration, scripts, documentation — add path filters:
on:
push:
branches:
- main
paths:
- 'content/**'
- 'data/**'
With this configuration, only pushes that touch files under content/ or data/ will trigger a Pages build. Pushes that only change CI configuration, README files, or scripts won't queue a build.
What Cloudflare returns and what it means
A successful POST to the hook URL returns a short JSON response:
{"id":"abc123def456"}
This confirms that Cloudflare accepted the trigger and started a build. It does not mean the build completed or succeeded — only that it entered the queue.
The workflow step completes as soon as the POST request returns. If you need to know whether the build actually succeeded, check the Cloudflare dashboard: Workers & Pages → your project → Deployments. The deployment triggered by the hook will appear there with its status.
Monitor build status from the workflow (optional)
If you need the GitHub Actions job itself to fail when the Pages build fails — for example, to block downstream steps — the basic Deploy Hook approach won't do it. You need the Cloudflare Pages REST API and an API token to poll for build completion.
GitHub Marketplace has third-party actions that handle this, but evaluate them before adding to a production workflow: check the maintenance status, required permissions, and whether they're actively maintained.
For most use cases, the Deploy Hook approach is sufficient. Failed builds are visible in Cloudflare's dashboard and can send notifications through Cloudflare's notification settings.
Avoid exhausting your monthly build quota
Cloudflare Pages Free plans allow 500 builds per month (Cloudflare Pages Limits). A busy trigger repository — one that receives many small commits daily — can exhaust this quickly.
Path filters (described above) are the first mitigation. If builds still accumulate faster than expected, consider replacing the push trigger with a scheduled workflow:
on:
schedule:
- cron: '0 */6 * * *' # every 6 hours
This triggers a Pages rebuild four times a day regardless of push activity, which fits content pipelines where recency matters but exact timing doesn't.
One case to watch: if the trigger repository is the same repository connected to your Pages project, a push will trigger two builds — one from the Git integration and one from the workflow hook. In the two-repo setup described here, this doesn't apply, but keep it in mind if you're adding a hook to the same repo Pages already watches.
Verified July 2026. Cloudflare Pages plan limits and UI may change — check the Cloudflare Pages documentation for current information.