A commit lands on a pull request
The push is the trigger. Nothing is scheduled and no workflow file is added to your repository.
TriggerInstall the app once and every pull request gets driven. IronBee reads what the commit changed, exercises it against the deployed preview, and posts what it found on the pull request itself.
The push is the trigger. Nothing is scheduled and no workflow file is added to your repository.
TriggerThe change is exercised while it is still under review, rather than after it has been merged.
TriggerRead-only repository access, used to see what the commit touched and to write the journey that change can break.
ActionA real browser against your real backend, on the build that pull request produced.
ActionThe run is posted by the bot: what was verified, what was found, and the verdict, all in one place.
ActionEach one described in full, with the behaviour observed live rather than inferred from the diff.
ActionThe important files the change touched, so the finding lands where the fix has to happen.
ActionThe diff to apply, ready to hand to Claude Code, Cursor or Codex without leaving the review.
ActionNo tab to open and no dashboard to check. What the agent did, what it found, and where it came from are in the thread with the change.
The app asks for what the verification agent needs to do its job and nothing beyond it.
The agent checks out your code during an automated verification. It does not write to your repository.
Choose the repositories the app can see when you install it, and change that at any time from GitHub.
What lands on the pull request is the verification: what was checked, what broke, and the files involved.
IronBee Verification
Verification failed