Now in closed beta.Book a demo to get started.
Use cases

Add the test that would have caught it

Incident follow-through|Everything this ticket has to prove is checked by machine, so it can be handed over as it is. A person still reads the pull request and decides whether to merge it.

The first action item on every postmortem, written as a test that fails against the commit that caused the outage.

The ticket

Write the test that would have caught the incident before it reached production.

Acceptance criteria

  • The test fails when run against the commit that caused the incident
  • It asserts the condition that broke, not the symptom that was noticed
  • It runs in the normal suite rather than a special one
  • The incident is referenced in the description

What lands as proof

The test run against the offending commit, failing. Anything else is a guess about what would have caught it.

Why teams defer it

  • By the time the postmortem is written the fix is already deployed, so the test feels like paperwork.
  • Reproducing the original condition often means recreating state that no longer exists.

Questions

What does the agent actually change?
The ticket is scoped to one outcome: write the test that would have caught the incident before it reached production. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
How do I know the work is done?
The pull request carries the evidence, not only the diff. Here that means the test fails against the commit that caused the incident, so a reviewer can confirm the result without reproducing the work locally.
How much oversight does this need?
None is required before the run starts. Every claim this ticket makes can be checked by machine, so the agent works straight through and a person reviews the finished pull request like any other.

Ready to put the fleet to work?

Contact us for a demo with an expert.