Deploy checks: Vercel, Netlify and GitHub Actions

How deploy checks work

• Each website has its own deploy hook URL. Anything that can send an HTTP POST can start a check: a CI step, a hosting provider's deploy notification, a script.
• The check is a full scan of the website's monitored pages against their approved baselines, the same as a scheduled scan, labelled as a deploy in the scan history.
• An optional JSON body like {"note":"v2.4.1"} labels the check with your release (up to 140 characters). Any other body is ignored, so a provider's own payload is fine.

1. 1

   Enable deploy checks

   In MyKavo open the website, go to Deploy checks and press Enable deploy checks.

2. 2

   Copy the deploy hook URL

   Copy the URL and store it as a secret in your CI or hosting provider. Anyone with it can start checks for this website, so keep it out of your repository.

GitHub Actions

Save the URL as a repository secret named MYKAVO_DEPLOY_HOOK (Settings > Secrets and variables > Actions), then add a step after the step that deploys to production. It only runs when the deploy succeeded, and labels the check with the short commit hash.

- name: Check the site with MyKavo
  if: success()
  env:
    MYKAVO_DEPLOY_HOOK: ${{ secrets.MYKAVO_DEPLOY_HOOK }}
  run: |
    curl -fsS -X POST "$MYKAVO_DEPLOY_HOOK" \
      -H "Content-Type: application/json" \
      -d "{\"note\":\"${GITHUB_SHA::7}\"}"

The same one-line curl works in any CI system - GitLab CI, CircleCI, Bitbucket Pipelines, Jenkins - after the production deploy step.

Netlify

In your Netlify site open the deploy notification settings and add an outgoing webhook for the Deploy succeeded event, with your deploy hook URL as the URL to notify. Netlify posts its deploy details as JSON; MyKavo ignores them and starts the check. If the site also builds deploy previews or branch deploys, they send the event too - each one starts a check of your production pages, so for busy sites prefer a step in your build or CI that runs only for production.

Vercel

If you deploy to production from CI with the Vercel CLI, add the curl step from the GitHub Actions example right after the production deploy command. On plans that include webhooks you can instead add a webhook in your Vercel team settings for the deployment succeeded event on your project, pointing at the deploy hook URL. Webhook events also fire for preview deployments, so the CI step is the better fit when you deploy previews often.

What the verdict looks like

• Nothing important changed: a "Deploy verified" notification, and the check appears in the scan history with your note.
• Something changed: the changes are listed by severity, each with previous and current values and before-and-after screenshots, and the check carries your note so you know which release it followed.
• Expected changes from the release can be approved in one go, which updates the baselines for the next deploy.

Security and limits

• The deploy hook URL works for one website and can only start a check. It cannot read data or change settings.
• If the URL leaks, regenerate it under Deploy checks. The old URL stops working immediately.
• Repeated calls are rate limited, and a call that arrives while a check is already running does not start a second one.

Frequently asked questions

More in plans, security and data

• Plans and limits
• The WordPress plugin: install, connect and Safe Updates
• Supabase: check your site when content or code changes
• How MyKavo crawls, and how it protects your network
• Your data, and what deletion actually deletes
• All documentation