What is PreMan? Release Impact and API Repair, Explained

Most API failures do not begin with an obvious outage. They begin with a normal release.

A route changes shape. A dependency behaves differently. The unit tests pass, but a downstream endpoint now returns the wrong status for one customer workflow. Monitoring eventually catches the symptom, then an engineer has to reconstruct which release caused it, who is affected, how to reproduce it, and what change will fix it.

PreMan closes that gap between shipping a change and repairing its real-world impact.

PreMan in one sentence

PreMan is release-to-repair infrastructure for APIs. It detects API changes at git push, tests the affected surface, identifies customers at risk, generates a verified fix, and keeps watching the endpoint in production.

The goal is not another dashboard or ticket queue. The goal is to give your team the evidence and proposed code change needed to resolve a regression while the context is still fresh.

The six-step release-to-repair loop

1. You git push

Ship through the repository and CI workflow you already use. PreMan starts from the commit instead of asking your team to copy requests into a separate collection or remember to run a manual suite.

2. PreMan detects the API changes

PreMan compares the release with the previous API contract and maps changed routes, schemas, and dependencies. This creates a focused change surface: what moved, and what could move with it.

3. PreMan tests every affected endpoint

A change to one handler can affect more than one route. PreMan runs focused regression checks and generated edge cases across the endpoints connected to the change, so verification follows the dependency graph rather than only the file in the commit.

4. PreMan finds impacted customers

An error rate alone does not tell you what to do first. PreMan connects affected endpoints to the users, accounts, and critical workflows that depend on them. Your team can see the likely blast radius and prioritize the release by customer impact.

5. PreMan generates a verified fix

When a check fails, PreMan packages the reproduction, expected and actual behavior, generated regression coverage, and a proposed repair into a fix PR.

“Verified” does not mean PreMan silently merges or deploys code. Automatic PR creation depends on a connected repository, GitHub access, Auto-PR opt-in, a completed simulation, and passing verification. Your team still reviews and controls the merge.

6. PreMan monitors production and repairs new errors

Pre-release tests cannot model every real request. After deployment, PreMan watches endpoint errors, latency, and failing production behavior. If a new regression appears, it traces the signal back to the change and opens another verified repair path with the production evidence attached.

That closes the loop: the same system that understood the release keeps responsibility for what happens after it ships.

What “self-healing” means here

Self-healing should not mean an opaque agent editing production without review. In PreMan, it means the path from failure to a reviewable repair is automated:

• the affected request is reproducible;
• the customer blast radius is visible;
• the proposed change includes regression coverage;
• the checks and production evidence travel with the PR; and
• the engineering team remains in control of merge and deployment.

PreMan removes the investigation handoffs. It does not remove your safety boundaries.

Where agents and MCP fit

PreMan can expose workflows through skills and MCP tools so Cursor, Claude Code, Codex, and other agents can run tests, inspect evidence, or participate in a repair. Those integrations are how teams use PreMan inside their existing tools; they are not the product story by themselves.

The product outcome is simpler: know what a release can break, know who will feel it, and get to a verified fix faster.

Who PreMan is for

PreMan is built for teams that:

• ship APIs used by real customers or internal critical workflows;
• cannot infer customer impact from a generic 500-rate alert;
• want endpoint testing tied to code changes rather than static collections;
• already use coding agents but need evidence and guardrails around generated fixes; or
• spend too much incident time reconstructing release context by hand.

If a normal git push can create a customer-facing regression, PreMan is designed to follow that change all the way through production repair.

→ Join the PreMan waitlist