From push to report

A change lands: a push to a pull request, a change on a branch you selected, or you asking SuperGorilla for a test in GitHub, the same way you’d ask a teammate. We get your app running, agents use it the way real users would, and a report lands back on the pull request: what was tried, what happened, and the evidence.

You configure which of those triggers apply, per project. Most teams start with every push to a pull request and adjust from there.

Virtually any web application works. SuperGorilla figures out how to run yours on its own. There is no staging URL to point at, no preview deploy to wire up, and nothing for you to stand up first. If your app won’t start, the run reports that too, with the output that explains why, and you aren’t billed for it.

Two sources. The change itself: the agent reads what the change is trying to do, works out which user flows it touches, and tests them the way a customer will. Your critical flows, coming soon: show the agent how to test a flow by recording it with SuperGorilla, walk through it once, and it tests that flow automatically on every change from then on.

Steering is optional. When the agent needs a hint, you brief it the way you’d brief a new tester: “Use the seeded account demo@acme.dev. Skip the onboarding tour. The payment form only takes the 4242 test card.” No selectors, no test code, just instructions in English.

Guardrails work the same way, but as hard limits: pages the agents stay out of, actions they never take, data they never touch. “Never place a real order. Don’t email anyone but the seeded accounts. Leave the admin panel alone.” Steering shapes a run; guardrails bound every run.

Four kinds of evidence, every run: a video of the whole session, a screenshot at every step, console and network logs captured while it happened, and for anything that broke, steps to reproduce with a severity rating. Enough to judge a finding in twenty seconds without reproducing it yourself.

Every run teaches it more about your app. Memory operates at five levels: organisation, project, repository, branch and pull request. It knows your conventions, this codebase’s gotchas, and what already passed or broke on this very PR. Tests get faster and quieter the longer you run them.

Honest limits, current as of now: web applications only; mobile and desktop are in development. Flows that require a real phone, real payment rails, or a human on the other end (live chat, phone verification) need test-mode equivalents. And like any tester, it can miss things; reports are evidence, not a guarantee.