Website monitoring GitHub Action
Add one step after your deploy. Relvato runs your monitors on the live site and fails the job when one finds a problem: a broken checkout, a page that looks different, a vulnerable plugin, an SEO regression, a missing legal page.
The Action uses Relvato's API, which every plan includes, Free too. It needs a site whose ownership is proven and a full-access API key.
Running in three steps
No app to install in GitHub: the Action calls Relvato's API with a key you keep as a repository secret.
Prove the site is yours
Add the site in Relvato and prove its ownership with the WordPress plugin, a DNS record or a meta tag. The API runs monitors only on proven sites.
Save a full-access key as a secret
In Relvato, open API access and create a key with full access. In GitHub, open Settings → Secrets and variables → Actions and save it as a repository secret named RELVATO_API_KEY.
Add the step after your deploy
Add Relvato/relvato-action@v1 to your workflow with the key and your site. It waits for the runs and fails the job when a monitor finds a problem.
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.examplesite takes the site's domain (myshop.example) or its Relvato site id. A read-only key can't start runs.
Run it once the deploy is live
Relvato runs your monitors against the site's address, so the step has to come after the deploy has reached production. It can't check a preview deployment before it's promoted.
After the deploy job in the same workflow
The verify job waits for deploy with needs. Here it runs only the flow monitors (checkout, logins, forms) and fails the job only on a high or critical problem.
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh
verify:
needs: deploy
runs-on: ubuntu-latest
steps:
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.example
group: flow # checkout, logins, forms
min-severity: highAfter a production deployment on Vercel, Netlify or another host that reports deployments to GitHub
The workflow starts on deployment_status and runs once the production deployment has succeeded: after it's live, not before promotion. The environment name is whatever your host reports (Vercel uses Production).
on: deployment_status
jobs:
verify:
if: github.event.deployment_status.state == 'success' && github.event.deployment.environment == 'Production'
runs-on: ubuntu-latest
steps:
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.exampleWhat a run from your workflow does
It looks at the live site
Relvato runs the monitors against your site's address. Put the step after the deploy reaches production: a preview deployment can't be checked before it's promoted.
It counts like Run now
Every run counts towards your plan's monthly runs, one per monitor. A problem it finds is also alerted on the channels in Alert settings, like any run you start by hand.
Couldn't run is a warning
When a firewall or bot protection blocked Relvato, the site didn't answer or the WordPress plugin is out of date, the monitor is a warning, not a failure: it says nothing about your deploy.
Only what a deploy can affect
Set group to run one monitor group, such as flow or security, and min-severity to the lowest severity that should fail the job.
Inputs
| Input | Default | What it does |
|---|---|---|
api-key | — | A full-access Relvato API key. Required. |
site | — | The site's domain (myshop.example) or its Relvato site id. Required. |
group | every monitor | Only one monitor group: uptime, flow (checkout, logins, forms), security, design, performance, seo, domain or compliance. |
fail-on | issue | issue: fail when a monitor finds a problem. any: also when a monitor couldn't run (a firewall blocked Relvato, the site was down) or the time ran out. never: report only. |
min-severity | low | The lowest severity that fails the job: warning, low, medium, high or critical. |
timeout-minutes | 20 | How long to wait. A site's monitors run one at a time, so a full set can take several minutes. |
Outputs
| Output | What it holds |
|---|---|
result | passed, issues, not-run or timeout |
issues | How many monitors found a problem at or above min-severity |
not-run | How many monitors couldn't run |
runs | Every run as JSON: id, monitor, outcome, severity, url |
site-url | The site's page in Relvato |
Report without failing
With fail-on: never the job doesn't fail; a later step can read the result output.
- uses: Relvato/relvato-action@v1
id: relvato
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.example
fail-on: never
- run: echo "Relvato says ${{ steps.relvato.outputs.result }}"Rather not write a workflow?
For a site added as Any website / AI-built app, you can connect the GitHub repository you deploy from with the Relvato GitHub App, or add the deploy webhook to GitLab, Netlify, Railway or Ghost. Relvato then re-runs the site's monitors on every push or deploy, and a problem reaches you through your usual alerts. The Action is for when you want the result in the workflow itself, and the job to fail on it.
The GitHub Action, answered
Which plans can use the GitHub Action?
Every plan, Free included: the Action uses Relvato's API, which every plan has. Each run counts towards your plan's monthly runs, one per monitor, so use group to run only the monitors a deploy can affect.
Can it check a Vercel or Netlify preview before it's promoted?
No. Relvato runs your monitors against the site's address, so it sees what's live. Run the step after the deploy has reached production, for example on deployment_status once the production deployment has succeeded.
What happens when a monitor couldn't run?
It's a warning in the job, not a failure: a firewall or bot protection blocked Relvato, the site didn't answer or the WordPress plugin is out of date, which says nothing about your deploy. Set fail-on: any to fail the job on it too.
Will a problem it finds also send an alert?
Yes. A run started from a workflow counts like Run now in the dashboard, so a problem it finds is also alerted on the channels you set in Alert settings (email, Slack, Teams, Discord, Telegram, PagerDuty, webhook).
Why does it need a full-access key?
A read-only key can read results but can't start runs. Create a full-access key under API access in Relvato and save it as a repository secret named RELVATO_API_KEY.
How long does it take?
A site's monitors run one at a time, so a full set can take several minutes. The Action waits up to timeout-minutes (20 by default). If runs are still going then, the result is timeout, which fails the job only with fail-on: any.
I've connected GitHub to Relvato. Do I need the Action too?
Only if you want the result in the workflow. The GitHub App re-runs your monitors on every push and tells you through your alerts. The Action runs when your workflow says, shows each monitor in the job summary and can fail the job.
Can I do the same without the Action?
Yes, over the REST API: POST /api/v1/sites/{id}/scan (optionally with {"group": "flow"}), then poll GET /api/v1/runs?siteId={id} until each run is finished, and read its outcome (ok, issue, not-run) and severity.
More ways to work with Relvato
Know the deploy worked before your visitors find out
Prove the site's ownership, create a full-access key and add one step to your workflow.