Scan after deploy
GitLab CI/CD
A .gitlab-ci.yml job that starts a scan after deploy.
Integration guide
Scan your website after every GitHub Actions deploy
Add one step to your GitHub Actions workflow and Rookflare scans your website right after every successful deploy, with the commit SHA attached.
Overview
What the GitHub Actions integration does
What it does
- Runs as the last step of the job that deploys, so the scan starts the moment your deploy step exits without an error.
- Sends github.sha as the ref. Re-running the same workflow, or a matrix that deploys the same commit twice, starts one scan.
- Works the same on GitHub-hosted and self-hosted runners; the runner only needs outbound HTTPS.
Before you start
- A Growth and Agency plan. The 14-day free trial runs on Growth, so you can set it up before you pay.
- A verified website in Rookflare with monitoring turned on, and the owner or admin role.
- A GitHub repository with a workflow that deploys your website, and permission to add Actions secrets.
Setup
Set up GitHub Actions step by step
-
Step 1
Create the deploy hook in Rookflare
Open the website, go to the Settings tab and select “Create deploy hook” in the “Scan after deploy” card. Copy the token right away: this is the only time Rookflare shows it in full. The card keeps the endpoint and the last four characters of the token.
The Scan after deploy card right after “Create deploy hook”: the full token is shown once, with the endpoint below it. -
Step 2
Add the token as a repository secret
In GitHub, open the repository’s Settings → Secrets and variables → Actions and add a new repository secret named ROOKFLARE_DEPLOY_TOKEN with the token as its value. If the deploy job uses a GitHub environment such as production, you can store it as an environment secret there instead, so only jobs for that environment can read it.
-
Step 3
Add the step after your deploy step
Paste this step at the end of the job that deploys. “if: success()” keeps it from running when the deploy fails, and curl’s -f flag fails the step when Rookflare rejects the call.
- name: Scan with Rookflare after deploy if: success() run: | curl -fsS -X POST "https://app.rookflare.example/api/webhooks/deploy" \ -H "Authorization: Bearer ${{ secrets.ROOKFLARE_DEPLOY_TOKEN }}" \ -H "Content-Type: application/json" \ -d '{"ref": "${{ github.sha }}"}'Sample endpoint and placeholder token. The dashboard fills in yours.
-
Step 4
Check the whole job
In a full workflow it sits after the deploy step of the same job. Replace the deploy step with yours. Keep it in the same job: a separate job would need “needs: deploy” to wait for the deploy to finish.
name: Deploy on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Deploy run: ./deploy.sh - name: Scan with Rookflare after deploy if: success() run: | curl -fsS -X POST "https://app.rookflare.example/api/webhooks/deploy" \ -H "Authorization: Bearer ${{ secrets.ROOKFLARE_DEPLOY_TOKEN }}" \ -H "Content-Type: application/json" \ -d '{"ref": "${{ github.sha }}"}'Sample endpoint and placeholder token. The dashboard fills in yours.
-
Step 5
Push to the deploy branch
Push a commit to main (or the branch your workflow deploys) and open the run in the Actions tab. The “Scan with Rookflare after deploy” step should finish green. In Rookflare, the card’s “Last used” shows the time of the call and the website’s Scan history lists a scan with the trigger “After deploy”.
The website’s Scan history: the newest scan has the trigger “After deploy” and is scanning; below it a scheduled scan and an earlier deploy scan, both completed.
Troubleshooting
If it does not work
-
The step was skipped
An earlier step in the job failed, so “if: success()” skipped the call. That is intended: Rookflare should not scan a deploy that did not happen. Fix the deploy and push again.
-
The token is empty in pull requests from forks
GitHub does not pass repository secrets to workflows triggered from forks, so the header has no token and Rookflare answers 401. Run the step only in the workflow that deploys from your own branch.
-
Nothing runs after a deploy made by another workflow
Events created with the built-in GITHUB_TOKEN do not start new workflow runs, except workflow_dispatch and repository_dispatch. Put the Rookflare step in the workflow that deploys, or trigger the follow-up workflow with workflow_run.
-
Rookflare answers with an error code
401 means a wrong, rotated or revoked token, 402 a plan or daily limit, 409 an unverified or paused website and 429 more than 30 calls a minute. The cURL guide explains each answer and what to do.
Where should the deploy token live?
In your deploy tool’s secret store, never in the repository. The token can only start scans of one website, and you can rotate or revoke it on the website’s Settings tab at any time; the old token stops working right away.
My host deploys the site, not GitHub Actions. Can a workflow still call Rookflare?
Yes, if the host reports deployments to GitHub. A workflow on the deployment_status event runs when a deployment status is created; give the job “if: github.event.deployment_status.state == 'success'” and compare github.event.deployment.environment with your production environment name. GITHUB_SHA is then the commit that was deployed.
Does it scan pull request previews?
No. Rookflare scans the pages of the website you added, which is your live site. Add the step only to the workflow that deploys to production; a preview environment has a different address that Rookflare does not monitor.
We deploy several apps from one repository. Where does the step go?
In the job that deploys the app behind the website you monitor. Each Rookflare website has its own token, so a second monitored site gets its own secret, for example ROOKFLARE_DEPLOY_TOKEN_SHOP, and its own step in that app’s deploy job.
Start monitoring your website
Add your address, pick the pages and approve the first scan as your baseline.
Plans start at €19 per month. Prices are provisional.