Skip to main content
This is the job most people connect Peeps for. You ask what went wrong, your agent pulls the evidence and reads it next to your local code, and together you decide what to do. Peeps self-heals script issues on its own. This page is for what healing hands back: a fix that needs your local code to get right, or a failure Peeps diagnosed as something other than a broken script.

​
Start from whatever you have

A Peeps link or id. Paste a run, test case or batch URL, or its id. Your agent opens that failure directly.
Why did this fail? https://app.peepsai.com/…
Nothing at all. Ask in plain English.
What’s failing in Peeps?
1

Your agent finds the project

It matches your checkout’s git remote to a Peeps project. If nothing matches, or more than one project could, it lists your projects and asks you which one.
2

It lists what is failing now

Asked about a recent period without naming a range, it looks back seven days. If that comes back empty, the answer says why — see reading the results.
3

You pick one

Or say “look at the first one”. Your agent opens it in full.
If a test case or batch has more than one failure, your agent shows you the candidates and asks which one you mean. It never quietly picks the newest.

​
What comes back

Opening a failure returns everything in a single response. Your agent can then pull one heavier artifact from the run when the evidence points at it. Screenshots and trace frames come back as images, DOM snapshots and network summaries as text, and traces and videos as a short-lived link you open yourself. Raw GitHub Actions logs are not available here. For a batch run, ask for the summary first:
Summarize last night’s regression batch.
You get the live counts and every member failing in it right now. Pick one to open in full.

​
Decide which kind of problem it is

Once you know the cause, there are exactly three paths. Your agent branches on the diagnosis rather than reaching for the same move every time.

​
Test-script problem

The application is fine; the script is wrong. Your agent proposes a script fix, Peeps verifies it in its own hosted run, and you approve publishing it. The steps are below.

​
Application bug

The test is right; your app is broken. Fix your app code locally as you normally would.
Re-running the test against the unchanged deployment is never verification of a local fix. Your code has to ship before a run can prove anything about it — and your agent will say so rather than presenting a rerun as a green light.

​
Intended behavior change

The app changed on purpose, and the test has not caught up. Your agent makes one combined proposal: the new script and the new steps together. They are published together, so the test never sits half-updated, with steps describing one behavior and a script asserting another. This one verifies normally, as long as the new behavior is already live in the environment the fix runs against.

​
How a fix goes live

1

Your agent shows you the fix plan

The plan carries the complete script change against the version that runs today, the test’s current steps, any step change, and the environment it will run in. Your agent tells you plainly when that environment is production. You approve running it.
2

Peeps verifies it in its own hosted run

Peeps freezes the exact bytes you approved, so the candidate cannot change after you saw it. Your agent follows the run until it settles. Verifying a fix never makes it live.
3

You review it and approve publishing

After a pass, your agent shows you the full review — the complete script change, any step changes, where it ran, and what publishing affects. It publishes only after you say so. Your organization’s owners and admins are notified.
If the environment, its variables or the tests around it changed since the run, the review asks for a recheck first. You approve the recheck run, and then review and approve publishing again. A passing run shows the script ran. It does not prove the fix still tests what the steps describe, which is why you read the diff. If you don’t want a suggested fix, ask your agent to dismiss it. The fix is retired, and its verification history stays.
Fix verification works on JavaScript or TypeScript Playwright test cases, one test per case. For a Python test, or a small script edit you want to publish without a verification run, see manage scripts.

​
Worked example: an intended behavior change

You: The checkout test failed on staging last night. What happened?
Your agent matches your checkout to the Peeps project and opens the latest checkout failure. It reports Peeps’s analysis: the test times out waiting for the payment form. The screenshot shows a new delivery-date picker in front of it. The last runs passed until yesterday.
You: That’s the delivery-date feature we shipped yesterday. Update the test.
Your agent reads your local checkout, confirms the feature is intended, and proposes one change with two parts:
  • a new step, “Choose the first available delivery date”, before payment
  • the matching script change, shown as a complete diff against the version that runs today
It shows you the plan: staging, not production, and the tests that run first. It asks whether to verify the fix there.
You: Yes, run it.
Peeps runs the candidate in its own hosted CI. Your agent follows it and reports that it passed. It then shows you the full review, including the step change, and asks whether to publish.
You: Publish it.
The new script and the new step go live together. Every future run of the checkout test uses them.

​
Keep the team in the loop

Link the failure to a Linear issue without leaving your editor. See Linear issues.
Link this failure to ENG-123.