What the agent does
Through the Datadog connection the agent reads the monitor, then the error logs and APM traces for the service from the 30 minutes around the alert. The Datadog Java agent names Spring MVC resources by their mapping, such as POST /owners/{ownerId}/pets/{petId}/visits/new, and attaches the exception class, message and stack trace to the error span. The agent counts errors per resource and exception before it reads any code.
In a Spring Boot app like spring-projects/spring-petclinic (Spring Boot 4.1.0 as the parent in pom.xml, Java 17), the owner and visit flows live in src/main/java/org/springframework/samples/petclinic/owner/. OwnerController maps /owners/new, /owners/find, /owners, /owners/{ownerId}/edit and /owners/{ownerId}. VisitController maps /owners/{ownerId}/pets/{petId}/visits/new and loads the owner with orElseThrow(() -> new IllegalArgumentException(...)), then throws again if the pet is missing. An IllegalArgumentException in the traces is therefore a lookup that found nothing, and the agent checks whether the id came from a stale link or from a form that lost it.
It also knows what not to fix. CrashController maps /oups and throws on purpose to demonstrate the error page, so errors on that resource are expected and the agent reports them as such. For a real bug, it writes a test in the matching file under src/test/java/.../owner/, such as VisitControllerTests, which uses @WebMvcTest(VisitController.class) with @MockitoBean repositories, so the test sets up the exact owner and pet state production had. It runs ./mvnw test. MySqlIntegrationTests is marked @Testcontainers(disabledWithoutDocker = true) and is skipped without Docker, and the agent says whether it ran.
It opens a pull request quoting the stack trace and log lines, naming the resource from the trace, linking the monitor and explaining what users hit, for example a 500 page instead of a not-found message when an owner was deleted.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "A Datadog monitor on this Spring Boot service fired; its webhook payload follows this prompt. Use the Datadog connection to read the monitor and the error logs and APM traces from the 30 minutes around the alert, counted per resource and exception. Find the code path that produced them in the owner and visit controllers under src/main/java/org/springframework/samples/petclinic/owner/. Treat errors from CrashController's /oups as expected. Write a JUnit regression test in the matching *ControllerTests class with @WebMvcTest and @MockitoBean, fix the code, run ./mvnw test, and open a pull request that quotes the log lines the fix addresses, links the monitor, and says whether the Testcontainers tests ran.\n\nMonitor payload:\n{payload}",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
],
"connections": [
"datadog"
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
A pull request comes back with the fix in a controller or the repository method it calls, and a new @Test method in the matching controller test class. The description quotes the stack trace, names the resource, links the monitor and lists the ./mvnw test result, including which test classes were skipped and why. Your CI runs the full build on it.
The session's result, delivered as data.result on the run.completed webhook, explains the cause. The transcript keeps the Datadog queries and the Maven output, so a reviewer can see the test count and the skipped classes for themselves instead of trusting a summary.
In review, check that the fix answers the right status: a missing owner should be a not-found page or a redirect with a message, not a 500 with a different exception. Check that the new test fails on the old code and that any change to OwnerRepository queries does not break ClinicServiceTests.
Run it on every Datadog monitor alert
In the Project for this service, add an automation with a webhook trigger, this prompt and a saved agent that names the Datadog connection. In Datadog's Webhooks integration, add a webhook to the trigger's URL with the trigger's secret as the bearer token and mention @webhook-<name> in the monitor. Each alert body follows the prompt as event text, and max_runs_per_hour limits runs from a noisy monitor.
If you would rather start runs from your own code, accept Datadog's webhook and call POST /o/{org}/sessions with this request, the payload in input and the alert id as Idempotency-Key. Set a webhook on the key to hear back when the pull request is open.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A Spring Boot fix needs a JDK, Maven's dependencies and a few minutes of build before the first test runs, which is exactly what nobody wants to set up when a monitor fires. A Rush run does it in its own sandbox, reads Datadog with your connection and runs ./mvnw test for real, keeping the build output on the session.
Each alert gets its own run and branch, so a controller bug and an unrelated monitor are handled side by side. The pull request carries the production stack trace and a test that reproduces it, and the transcript shows which tests ran and which were skipped, so the reviewer knows what was and was not proven.
Frequently asked questions
Will it run the MySQL and Postgres integration tests?
Those classes use Testcontainers and skip themselves without Docker. The agent reports whether they ran; if your prompt asks for them, it can start Docker in the sandbox and run them.
Does it handle Gradle projects too?
Yes. It uses the build the repository has: ./mvnw test here, ./gradlew test where there is a Gradle wrapper. Name the command in the prompt if you use something else.
What about errors that are expected, like a demo crash endpoint?
Name them in the prompt, as this request does for /oups. The agent then reports those errors as expected and looks for the real cause elsewhere, or says the monitor's query should exclude them.
Can it change the Datadog monitor?
The prompt keeps it to reading the monitor, logs and traces, and every Datadog call is in the transcript. Connect with a read-only key for a hard limit.