What the agent does
The agent reads the service before it adds an extension. In a project shaped like the hibernate-orm-panache-quickstart in quarkusio/quarkus-quickstarts, pom.xml imports the Quarkus platform BOM at 3.40.1.1, compiles for Java 17, and depends on quarkus-hibernate-orm-panache, quarkus-rest-jackson and quarkus-jdbc-postgresql, with quarkus-junit and REST Assured for tests. src/main/resources/application.properties sets a datasource only under the %prod profile, so development and tests get a PostgreSQL container from Dev Services, as the README's dev-mode section says. The resources in org.acme.hibernate.orm.panache serve /entity/fruits and /repository/fruits, and import.sql seeds Cherry, Apple and Banana, which FruitsEndpointTest lists and deletes with @QuarkusTest, and FruitsEndpointIT repeats against the packaged application with @QuarkusIntegrationTest.
The same repository holds the reference. The sibling microprofile-health-quickstart depends on quarkus-smallrye-health and has SimpleHealthCheck for liveness, DatabaseConnectionHealthCheck with @Readiness that returns down() with an error entry when it cannot reach the database, StartupHealthCheck, and a HealthCheckTest that reads /q/health/live with REST Assured and asserts status is UP and each check's name. The agent reads those files so the new code matches the conventions the maintainers already accepted.
The change is one dependency and one class. quarkus-smallrye-health goes into pom.xml with no version, since the BOM manages it, which registers /q/health, /q/health/live, /q/health/ready and /q/health/started. With the extension present, the Agroal datasource contributes its own readiness check, so the database connection is covered without code. The agent adds org.acme.hibernate.orm.panache.health.FruitsReadinessCheck, an @ApplicationScoped @Readiness check that runs FruitEntity.count() and reports the count as data, so readiness means the schema is in place and queryable rather than only that a connection opens. Imports are written out in full, because the pull request workflow at the repository root rejects star imports.
The test follows HealthCheckTest. A new HealthEndpointTest with @QuarkusTest asserts /q/health/live is UP, asserts /q/health/ready is UP and lists both the datasource check and the fruits check by name with the seeded count, and asserts /q/health aggregates them. The agent runs ./mvnw test in the quickstart directory, with Docker available for the Dev Services PostgreSQL container, and then ./mvnw verify so FruitsEndpointIT still passes against the packaged jar.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Add health checks to this Quarkus service. Read pom.xml, src/main/resources/application.properties, the resources under src/main/java and the tests under src/test/java first. Add the quarkus-smallrye-health extension with no explicit version, add a @Readiness check that counts the main entity through Panache and reports the count as data, keep the datasource readiness check the extension contributes, write a @QuarkusTest that asserts /q/health/live, /q/health/ready and /q/health with the check names, use full imports rather than star imports, run ./mvnw test and ./mvnw verify, and open a pull request that lists the endpoints and what each check reports.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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
What comes back is a pull request on its own branch. The diff adds one <dependency> to pom.xml, one class under src/main/java/org/acme/hibernate/orm/panache/health/, and one test under src/test/java/org/acme/hibernate/orm/panache/. No property changes are needed, because the health endpoints are on by default under /q. The description lists the four endpoints, names the two readiness checks and what each reports, and gives the probe paths and port a Kubernetes manifest or a HEALTHCHECK would use, since src/main/docker/Dockerfile.jvm exposes 8080.
The checks are the proof. The repository's pull request workflow builds every quickstart with ./mvnw -e -B -fae clean install -Dstart-containers on JDK 21 after its star-import check, so the new test runs there too. The session's trajectory at GET /o/{org}/sessions/{id}/messages keeps the ./mvnw test and ./mvnw verify output, including Dev Services starting the PostgreSQL container, so a reviewer reads the health test passing rather than taking it on trust.
Before merging, a reviewer checks that the readiness check's query is cheap enough to run on every probe, that nothing sensitive leaks through the check's data entries, and that /q/health is not exposed beyond the cluster or the load balancer that needs it. Nothing reaches main until the pull request merges.
Run it on every new service repository
A team that stamps out services from a template adds this run to the step that creates the repository: POST /o/{org}/sessions with this prompt and the new repository in resources, once the Rush GitHub App covers it. GET /o/{org}/github lists every repository the installation can reach, so a script can also sweep existing services for a pom.xml with the Quarkus BOM and no quarkus-smallrye-health and start one run each. A request_id built from the repository name makes a retried request return the run it already started.
Give the key a webhook_url and each run POSTs run.completed with its session_url when the turn finishes, so the pull request links collect on your side without polling. A key has at most max_concurrent runs in progress at once, 4 by default, and a further start is 429, so a sweep over many services should feed them in as runs finish.
The use case this job follows, with its automation and trigger: Hand off from your terminal.
Why run it on Rush?
A health check is only known to work when the readiness endpoint has been read while the database was up and while it was down, and on a laptop that means a JDK, Maven, Docker for the Dev Services container and a few minutes of Quarkus starting and stopping, repeated for each change. On Rush the agent does that in its own sandbox: it runs ./mvnw test, reads /q/health/ready from the test, and pushes only when the suite is green.
The result is checkable rather than claimed. The pull request carries the dependency, the check and the test; the repository's own pull request workflow builds it; and the trajectory keeps every Maven invocation with its output. A sweep over a dozen services means a dozen sandboxes and a dozen independent pull requests, each with its own evidence, instead of a dozen serial checkouts.
Frequently asked questions
Do I need to write a database check myself?
No. Once quarkus-smallrye-health is on the classpath, the Agroal datasource extension registers its own readiness check for every configured datasource. The added FruitsReadinessCheck goes one step further and runs a Panache count, so readiness also proves the schema answers queries. If you only want the connection check, the pull request is one class smaller.
Which endpoints does this add?
/q/health for everything, /q/health/live for liveness, /q/health/ready for readiness and /q/health/started for startup, all answering JSON with a top-level status and a checks array. The test reads the first three. The /q prefix is Quarkus's default for non-application endpoints and is unchanged here.
How do the tests get a database?
From Dev Services. application.properties configures a datasource only under %prod, so @QuarkusTest starts a PostgreSQL container through the quarkus-jdbc-postgresql extension, the same way dev mode does. The sandbox runs Docker for it, and the trajectory shows the container starting.
Will the existing fruit tests still pass?
Yes. FruitsEndpointTest and FruitsEndpointIT are untouched, and the agent runs ./mvnw verify so both the @QuarkusTest and the @QuarkusIntegrationTest run before the pull request opens. The health extension adds endpoints under /q and changes nothing under /entity or /repository.