# Add Health Checks to a Quarkus Service

Yes. An agent adds SmallRye Health to a Quarkus service with a readiness check on its database, tests the /q/health endpoints, and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/add-health-checks/quarkus/), in a Project that has your repository.

## 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`

```json
{
  "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"
    }
  ]
}
```

1. **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.
2. **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.
3. **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.

## 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`.