QA across every repository your team ships

Install the GitHub App on your organization and pick the repositories. Each one keeps its own settings, so the marketing site and the dashboard do not have to share a test.

• When it runs: every push, once when the pull request opens or is ready for review, or only when a member comments @zeusqa run. Drafts can be skipped, and path filters keep it to the changes that matter.
• What it tests: the preview deployment GitHub reports for the commit (Vercel, Netlify, Cloudflare Pages or any provider that posts deployments), a URL pattern built from {pr}, {branch} and {sha}, a fixed staging URL, or the project's base URL.
• How it tests: the prompt or preset, the model, and the devices: laptop, tablet or phone.
• Whether it blocks: merge blocking is set per repository and on by default.

Every run posts a ZeusQA check on the commit and a comment on the pull request with the verdict, each acceptance criterion marked met or not, the checks, findings and screenshots. A re-run of the same commit updates the comment in place.

A failing run fails the check. Each repository picks the severity that blocks, High by default: a run that fails only on findings below it reports as neutral, while a failed check or an unmet criterion always blocks. Make ZeusQA a required check in branch protection and the merge waits. On a repository where the run should only advise, turn merge blocking off and a failing run reports as neutral instead.

• Everyone in the workspace sees the same runs, projects and connections.
• Owners and admins connect GitHub, change repository settings, manage billing, and invite or remove members.
• Invites are a Team feature. Free and Pro have one member each.
• Pull request runs start on their own only for branches in the repository. Fork pull requests do not run on their own, their title and description never reach the agent, and only the repository's owners, members and collaborators can start a run with @zeusqa run.

Team gives the workspace 1,500 runs a month, 5 running at once, up to 60 steps a run and 50 schedules. Pull request runs, scheduled runs and runs started by hand all draw from the same pool, so nobody has to ask whose seat a test belongs to.

• Trends: runs per week by verdict with the pass rate, findings by severity, a table by project and a table by week, over 4, 12 or 26 weeks, each table with a CSV download.
• Security posture: the Security view of Trends tracks each security issue a run finds until a later run loads the same page or file (for a served source map, a script from the host that served it) and no longer sees it, with the mean time to fix, an OWASP Top 10:2025 table, and a CSV or PDF report.
• Email summaries: daily, weekly or monthly at 8:00 in each person's time zone, for anyone who turns them on.
• Schedule emails: when a schedule starts failing, and when it passes again.

Open the app, try the change described in the pull request, then check that the main navigation still reaches every top-level page and that each one loads without an error. Report anything broken, and check computer.diagnostics() for console errors and failed requests.

The pull request's title and description reach the agent with this prompt, so one saved prompt per repository covers both the change and the regression check.

• A verdict: pass, fail or blocked.
• Named checks, each marked passed or not, so you can see what was actually asserted.
• Findings rated critical, high, medium, low or info, with the evidence behind each one.
• A screenshot for every step, plus a session video on Pro and Team when you turn recording on.
• Console errors, uncaught page errors and failed or 4xx/5xx requests, collected automatically.
• Passive security findings from the responses the run loaded: headers, cookies, mixed content, open redirects, source maps, leaked secrets and stack traces.

Worth knowing before you point it at something important.

• No single sign-on. Members sign in with an email address and a password.
• No independent audit or certification yet, so there is no third-party report for a vendor review.
• GitHub only. No GitLab or Bitbucket.
• Run alerts are email only. Slack and Discord webhooks carry vulnerability advisories, not run results.
• Schedules run at most hourly.
• No choice of region for run data.