# Fix a NestJS API From a Grafana Alert

Yes. The alert starts a run that queries its metric and Loki logs through Grafana, traces the error to a module and opens a pull request with a Jest test.

[Run this on Rush](https://cloud.getrush.ai/run/fix-grafana-alerts/nestjs/), in a Project that has your repository.

## What the agent does

The Grafana Cloud notification arrives at a Rush webhook trigger and follows the prompt as untrusted data. The agent reads the alert rule through the Grafana connection, reruns its PromQL around `startsAt`, and searches Loki for the API's error lines in that window. A NestJS stack trace names the controller and the provider method, which is usually enough to tell an auth failure from a users failure before reading any code.

In an API like `brocoders/nestjs-boilerplate` (NestJS 11.1.18, TypeORM 0.3.28, Node 24.14.1 in `.nvmrc`), login is `validateLogin` in `src/auth/auth.service.ts`: it calls `usersService.findByEmail`, throws through `invalidLoginException` for a missing user, a social-only account or a wrong password, compares with `bcrypt.compare`, then creates a session through `sessionService.create`. Users live behind a ports-and-adapters layout, `src/users/users.service.ts` over `src/users/infrastructure/persistence/relational/repositories/user.repository.ts` and `user.mapper.ts`, with a parallel `document` adapter for MongoDB. A spike in 5xx on `POST /api/v1/auth/email/login` and a `QueryFailedError` in the logs send the agent to the repository and mapper, not the controller.

The repository has no unit tests yet: Jest's `testRegex` is `.*\.spec\.ts$` with `rootDir: src`, and the existing suites are e2e specs in `test/user/auth.e2e-spec.ts` and `test/admin/` that need the API and a database running through Docker Compose. So the agent adds a `.spec.ts` beside the failing provider, builds it with `Test.createTestingModule` and the real class under test, and reproduces the exception from the logs. Where the failure is in the query itself, it also starts PostgreSQL in the sandbox with the values from `env-example-relational` and runs the matching e2e spec.

It fixes the provider, repository or mapper, then runs `npm test`, `npm run lint` and `npm run build` so the change compiles under `tsconfig.build.json` and passes the ESLint config the project ships.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A Grafana alert fired for this NestJS service; its payload follows this prompt. Use the Grafana connection to read the alert rule, run its Prometheus query around the firing time, and query the Loki error logs for the same window. Follow the stack trace to the cause in the auth and users modules, add a Jest test that reproduces it, fix it, and run npm test, npm run lint and npm run build. Open a pull request that includes the PromQL and LogQL queries, the log lines behind the diagnosis, and the test output before and after the fix. If the evidence does not point at code, say what it points at instead.",
  "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 with the rule's PromQL and the values that crossed its threshold, the LogQL query and the stack trace it returned, and a new `.spec.ts` that fails before the fix and passes after it. The diff is the spec and the fix in `src/auth/` or `src/users/`; a change to an entity or migration is listed separately because it changes the schema.

A reviewer checks the spec reproduces the exception from the logs, that a fix in `validateLogin` still answers a wrong password and an unknown email the same way, so the endpoint does not reveal which accounts exist, and that the relational and document adapters stay consistent when one of them changed.

When the logs point at the database, a mail provider or an expired secret rather than code, the run explains that with the lines it found and opens no pull request.

## Run it on every Grafana alert on the API

Set up an automation in the Project with this prompt and a `webhook` trigger. In Grafana Cloud, add a webhook contact point at the trigger's URL with the header `Authorization: Bearer <secret>`, and send this API's alert rules to it. Each notification becomes the event the agent reads under the prompt.

Disable resolved messages on the contact point and keep the policy's repeat interval longer than a run, since a delivery without an `Idempotency-Key` header always starts a fresh run. A login outage that trips several rules at once is easier to read as one grouped notification.

## Why run it on Rush?

The steps from a red login graph to a fix are mechanical but slow: rerun the query, find the trace in Loki, map the provider to its adapter, then stand up Postgres and the API to reproduce it. A Rush run does that in its own sandbox and keeps every query, test and build in the session, so a reviewer can follow the diagnosis line by line.

Auth incidents tend to come with neighbours, a users endpoint and a session refresh failing together. Each alert gets its own run in parallel on its own branch, nothing runs against production, and each ends in a pull request whose spec proves the fix or a report of what the data shows.

## Frequently asked questions

### My project has no unit tests. What does it add?

A `.spec.ts` beside the failing provider, which matches Jest's `testRegex` in `package.json`, so `npm test` picks it up with no config change. It tests the real class, not a mock of it.

### Does it work with the MongoDB adapter too?

Yes. The boilerplate has `relational` and `document` persistence adapters for users; the agent fixes the one the logs implicate and checks the other has the same behaviour.

### Does it run the e2e tests?

When the failure needs a database to reproduce, it starts one in the sandbox and runs the matching spec under `test/` with `npm run test:e2e`. Otherwise the unit spec is the proof.

### Can the alert payload tell the agent what to do?

No. Rush hands the payload to the agent as untrusted data under the automation's own prompt, so text inside an alert annotation cannot replace the instructions.