Skip to main content
The agent verifies every merged pull request against production. It writes checks from the diff while the change is still in review, runs them after each deploy, and reports on the pull request. It is on for every connected repository; the only setup is the deploy signal.

​
The plan

When a pull request opens, the agent reads the diff and writes two kinds of checks: the effect the change promises and what the touched code could break. A latency fix that does not drop latency counts as a regression too. Each signal is measured before the merge, so every check compares against a real baseline; a check with too little traffic to judge never counts against the change. The plan is one review comment:
The agent edits this one review in place, and never approves, requests changes, or blocks a merge. If the change evolves before it merges, ask the agent to revise the plan. Changes that cannot alter runtime behavior (docs, lockfiles, formatting, CI config, tests) are skipped without a comment.

​
After the merge

Verification starts at the first successful deploy into each of your environments, in the order you deploy them. The clock starts at the deploy, not the merge. Checks run continuously for the first 10 minutes, then once at 1 hour, 24 hours, and 72 hours. For a risky change, like a data migration or a payment path, the agent watches longer and says so in the plan. The review’s last line is the status: armed — awaiting merge, then armed — awaiting deploy, then soaking with a checkpoint count. It ends one of four ways:
  • verified — every check held through the last checkpoint.
  • regression — a check tripped; the line names it and links the incident.
  • inconclusive — no deploy observed within 30 days.
  • retired — the pull request closed without merging.
The status names the environment once your deploy signal labels one.

​
When a check trips

A regression opens an incident, like any armed monitor firing (see Incidents and Slack). The agent first looks for another explanation, like a parallel deploy or an upstream outage; if that clears the pull request, it resolves the incident and records the explanation. Otherwise the agent proposes a revert or a fix. Merging it is up to you.

​
When every check holds

The agent ticks the checkboxes, sets the status to verified, and deletes the temporary monitor. No incident, no Slack message, no row left on the Monitors screen.

​
Where it shows up

Besides the review: pull requests the agent opened carry a verification footer on Home, the Monitors screen shows a changes/… row per pull request in flight, and the Deploys dashboard shows a verdict per version and environment for the last 30 days.

​
What it needs

A connected repository covers every pull request opened after connecting, drafts included. The one thing OnePatch has to work out is the deploy signal: which of your CI/CD events means “this shipped”. The agent settles it from your GitHub workflow runs, deployment statuses, and commit statuses. Plans written before then say so; ask the agent to re-arm them. If no GitHub event reflects your deploys, ask the agent to set the signal by hand.
If your deploys happen where GitHub cannot see them, the agent may open a pull request adding one line to your deploy step: a curl that reports “deployed” to the telemetry endpoint your apps already use. Decline it and the agent uses the best signal it can see.

​
Limits and turning it off

Up to 20 changes verify at once; a pull request past the limit waits for capacity, and is skipped after three days. To stop verifying a repository, or all of them, ask the agent. Stopping applies to new pull requests; changes in flight finish. Once one repository is excluded, coverage becomes an explicit list, and repositories you connect later must be added to it.