✓

Check every release.

A release is when things break. Add one step to your GitHub workflow, and CheckMyApp uses your deployed app the way a real user would right after each deploy — and tells you in the job whether it still works.

One step

The step is a GitHub Action, CheckMyApp — check this release, on the GitHub Marketplace. Put it after your deploy:

workflow step
- uses: sorokinvj/checkmyapp-action@v1
  with:
    api-key: ${{ secrets.CHECKMYAPP_API_KEY }}
    url: https://your-app.com

Create an API key (the same key your agent uses) and save it as a repository secret named CHECKMYAPP_API_KEY. Keys come with every plan.

The job summary shows the verdict, what is new since the previous check — each finding linked to the verdict — and what the check cost. The verdict names the commit you shipped.

Where it goes in your workflow

Your host deploys for you (Vercel and others with a GitHub integration). They report each deployment to GitHub, and the check takes the address from the deployment itself:

.github/workflows/check-release.yml
name: Check the release
on: deployment_status

jobs:
  check:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: sorokinvj/checkmyapp-action@v1
        with:
          api-key: ${{ secrets.CHECKMYAPP_API_KEY }}
          # Production deploys are checked as your app; everything else as a throwaway preview.
          preview: ${{ !startsWith(github.event.deployment_status.environment, 'Production') }}

Your workflow deploys the app. Add a job after the deploy. With app-id the check uses everything you saved for the app: its test logins, the scenarios that must keep working, and the places it must not go.

after your deploy job
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

  check:
    needs: deploy
    runs-on: ubuntu-latest
    steps:
      - uses: sorokinvj/checkmyapp-action@v1
        with:
          api-key: ${{ secrets.CHECKMYAPP_API_KEY }}
          app-id: cm0yourappid        # the id in your app's dashboard address
          notes: ${{ github.event.head_commit.message }}

Pull request previews. Check a preview before it merges. A preview check is private, is deleted after about a week, and never shows up as an app of yours.

in your preview job
- uses: sorokinvj/checkmyapp-action@v1
  with:
    api-key: ${{ secrets.CHECKMYAPP_API_KEY }}
    url: ${{ steps.deploy.outputs.url }}
    preview: true
    sha: ${{ github.event.pull_request.head.sha }}
    fail-on: needs_attention

Stop a broken release

By default the job fails when the verdict is broken. Set fail-on: needs_attention to be stricter, or fail-on: never to only report.

  • A full check usually takes 15–35 minutes. To keep the job short, set wait: false: the step starts the check and finishes, and the verdict appears on its page.
  • If a check of the same app was already running when the release landed, the step waits for it and then checks this build — the verdict is always about the commit you shipped.

What it costs

Every check has its own price, paid from your balance like any other check: about $0.50–$1.50 for a full check of a typical app, a few cents when nothing changed since the last one. The job summary shows what each check cost and what it did for that price. Plans are on Pricing.

Any CI can start the same check with one request after the deploy:

terminal
curl -X POST https://checkmyapp.dev/api/checks \
  -H "Authorization: Bearer $CHECKMYAPP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://your-app.com","deploy":{"sha":"'"$COMMIT_SHA"'","env":"production"}}'

The answer carries the check’s id; its verdict is at checkmyapp.dev/verdict/<id>. Your coding agent can do the same with start_check and a deploy_sha.

Check your app → · first run is free, no signup.